Automatic up-to-date containers using nightly samba builds

[gd]

=> so that we can easier access upstream changes (new ODJ code, packaging of mutex helpers, etc.)

[anoopcs9]

IIUC, intention here is to have samba-container images consuming nightly builds created every nightly as part of CentOS CI job(for Fedora & CentOS)?

[phlogistonjohn]

IIUC, intention here is to have samba-container images consuming nightly builds created every nightly as part of CentOS CI job(for Fedora & CentOS)?

From my POV that would be an acceptable approach. The other approach would be to have container builds directly consume samba sources and produce images with samba binaries that way.

The former is probably a lot less work in the short term and would probably be preferable until we find we have a need to have customized builds or something.

[obnoxxx]

IIUC, intention here is to have samba-container images consuming nightly builds created every nightly as part of CentOS CI job(for Fedora & CentOS)?

From my POV that would be an acceptable approach. The other approach would be to have container builds directly consume samba sources and produce images with samba binaries that way.

The former is probably a lot less work in the short term and would probably be preferable until we find we have a need to have customized builds or something.

I agree. Let's consume our nightly RPMs. The <= 24 hr lag is not a problem.

[anoopcs9]

I made the following change after realizing that --log-stdout command line option for bringing up smbd changed to --debug-output and it works now with nightly built rpms:

diff --git a/images/server/Dockerfile.fedora b/images/server/Dockerfile.fedora
index 902971a..4eadac9 100644
--- a/images/server/Dockerfile.fedora
+++ b/images/server/Dockerfile.fedora
@@ -1,6 +1,6 @@
 FROM quay.io/samba.org/sambacc:latest AS builder
-ARG SAMBACC_VER=a2cfac7ae49e
-ARG SAMBACC_REPO=
+ARG SAMBACC_VER=e3e2a53bea5d
+ARG SAMBACC_REPO=https://github.com/anoopcs9/sambacc.git
 
 # the changeset hash on the next line ensures we get a specifc
 # version of sambacc. When sambacc actually gets tagged, it should
@@ -13,6 +13,7 @@ MAINTAINER John Mulligan <jmulligan@redhat.com>
 ENV SAMBACC_VERSION="0.1"
 
 COPY smb.conf /etc/samba/smb.conf
+RUN curl http://artifacts.ci.centos.org/gluster/nightly-samba/master/fedora/samba-nightly-master.repo -o /etc/yum.repos.d/samba-nightly-master.repo
 RUN dnf install -y \
     findutils \
     python-pip \

samba-container

$ docker run --name samba --publish 10445:445 --volume=/tmp/share:/share:Z --rm quay.io/samba.org/samba-server:latest
smbd version 4.16.0pre1-UNKNOWN started.
Copyright Andrew Tridgell and the Samba Team 1992-2021

$ docker exec -it samba /bin/bash
[root@223df62a3399 /]# rpm -q samba
samba-20210918.005328.cf4a868be50-1.fc34.x86_64

client connecting...

$ smbclient \\\\localhost\\share -U sambauser%samba -p 10445
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Mon Sep 20 17:34:43 2021
  ..                                  D        0  Mon Sep 20 17:32:03 2021
  foobar                              N        0  Mon Sep 20 17:34:43 2021

		16320992 blocks of size 1024. 15392380 blocks available

[phlogistonjohn]

I made the following change after realizing that --log-stdout command line option for bringing up smbd changed to --debug-output and it works now with nightly built rpms:

Great, I'm glad the workaround allows us to use these recent samba builds. We will probably need a longer term strategy to deal with different samba versions in sambacc code. The two ideas I had were to either run a command (samba --version or similar) to probe for what options will be supported OR have an environment variable just tell sambacc what features to expect. Because sambacc is really only meant to be used in a container I think having the environment variable in the image is actually a pretty good option (on a non-container system I probably wouldn't be so positive on it).

Any thoughts?

[anoopcs9]

I made the following change after realizing that --log-stdout command line option for bringing up smbd changed to --debug-output and it works now with nightly built rpms:

Great, I'm glad the workaround allows us to use these recent samba builds. We will probably need a longer term strategy to deal with different samba versions in sambacc code. The two ideas I had were to either run a command (samba --version or similar) to probe for what options will be supported OR have an environment variable just tell sambacc what features to expect. Because sambacc is really only meant to be used in a container I think having the environment variable in the image is actually a pretty good option (on a non-container system I probably wouldn't be so positive on it).

Any thoughts?

I'm fine with environment variable. Let's go for it.

[phlogistonjohn]

I've created an issue in sambacc for this. If you want to work on it please do so, otherwise I'll get to in it in within a few days.

[phlogistonjohn]

done for a while.