rucio / containers Goto Github PK

Thanks for supporting this!

I was trying to build an fts image but get this error:

--> Finished Dependency Resolution
Error: Package: fts-monitoring-3.12.0-1.el7.cern.noarch (fts3-prod-el7)
           Requires: rh-python36-mod_wsgi

it is found in centos-release-scl-rh, adding it completes the build.

But I am not sure this is right.

Could you help to clarify?

Containers for non-versioned services only push to the latest tag. This can lead to situations, where the latest image gets overridden with a change that may work for the latest rucio release, but could break the previous releases. Therefore, versioning of all the containers can help save some nasty debugging scenarios.

In order to write Belle II specific tests, a new image including rucio.cfg with Belle II parameters is needed as well as a specific rse_repository.json that contains RSEs matching the RSE pattern (no underscore)

The hermes daemon container needs sendmail installed and running. I'm going to hack together something for CMS and then we can discuss if that's the best way or if a more elegant solution is better.

Just FYI

The current containers for webui were written for the React project developed during GSoC 2022. The webui has been re-written since then and we should update the containers for the latest codebase.

The steps ( from the top of my head) are:

Dockerfile

• clone the src code from a release tag in rucio/webui. The release tag is supplied as a build-arg to the docker build command
• npm run build

Entrypoint

• Prepare a .env file ( look at the .env.development.local.template in rucio/webui). The env variables can be provided via --env arg to docker run command or a file mounted to the container.
• npm run (to start the nextjs server)

Some concerns

• We need to investigate where the SSL certs for the webui should be placed. Until the last version, we had an httpd server for TLS termination, however, it should be possible to run the container behind a reverse proxy/load balancer that also takes care of TLS termination.

• We need to check if the SSL Peer Certificate requests are not blocked anywhere in the pipeline so that the end-users see the popup to select a x509 certificate in their browser.

• We need a way to mount images to the container in k8s ( logos of the collaboration, branding content). I don't know how we want to do this. At least from the container's point of view, we can have a dedicated volume mount and the entrypoint should move the image to the public directory before running the npm build command. In this case, the npm build should happen within the entrypoint and not in the Dokcerfile.

This is a setting CMS needs

Motivation

Using the container for testing RSEs, the CERN CA was not recognized.

Modification

Install CERN CA in the Dockerfile and thus update the image.

Expected results

CERN certificates are trusted.

Motivation

While trying to create a valid x509up certificate out of a grid robot certificate from a service account at CERN to connect Rucio to FTS, I had the following issues with the ft-cron container:

• the renew script requires specific values for the cert and key file
• permission on the files might not be sufficient for voms-proxy-init
• a password input is required for voms-proxy-init

In general, the helm input and handling of different VOs and their respective certificates should be improved.

With this issue, I might also tackle #177

Modification

I suggest changes to the helm chart of the FTS cronjob and script to allow the use of different filenames, as well as a third input option for a password.
Also add additional documentation for the FTS Cron (Container).

Expected results

A improved helm chart and script, so that users do not need to worry about file names and can provide an additional secret for their PEM password.

I am running the default rucio-server container image and I was informed by the CERN security team that it is vulnerable to an "http TRACE XSS attack".

Their suggestion was to include this after each virtualhost on the httpd config:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Does this have any downsides? Is there any use for the TRACE and TRACK methods?
If not I could do a PR with the fix.

Motivation

.bashrc does j2 rucio.cfg.j2 > /opt/rucio/etc/rucio.cfg

but rucio.cfg.j2 is in / and not in /root

Modification

call with absolute path:
j2 /rucio.cfg.j2 > /opt/rucio/etc/rucio.cfg

Starting here

some variables are tracer, some are tracer_kronos. Unless this is intentional, they should all be tracer_kronos.

Let me know and I'll fix it and patch it.

Heya,

I'm using the ESCAPE-derived Rucio client container (https://github.com/ESCAPE-WP2/Rucio-Client-Containers). When I start the container (either Singularity or docker) I get the following two errors:

bash: register-python-argcomplete: command not found

This seems to come from here:
https://github.com/rucio/containers/blob/master/clients/Dockerfile#L39
https://github.com/rucio/containers/blob/master/clients/init_rucio.sh#L14

I can make the error go away by installing the python-argcomplete package, but that looks like a python2 package and I don;t really know whether it actualy fixes the functionality (because to be fair I don't really know how to test). I read on 'the Internet' that there is also a python3-argcomplete package, but I couldn't find it in the yum repo.

So I decided not to just blindly do a pull request but open an issue so that someone who knows this much better than me could weigh in / investigate.

Usable by any Community, config can be specified (or container included in a wrapper container)

With reference to ESCAPE-WP2/Rucio-Client-Containers#34 it seems that the main problem is that there is no aarch64 version of the Docker image. This causes problems with at least the libgfal_plugin_gridftp.so library which is required to upload files, therefore, this functionality is not working when using e.g. a Mac(Book) with an M1 chip, which are getting more and more popular.

Is this a known issue? Are there any plans to offer cross-compiled arm64 images?

Hello,

The rucio-fs container is based on the rucio-clients one, with the addition of the fuse-posix module.

Possibly, the release version of the rucio-clients and that of the fuse-posix module are unaligned and, at the same time, a new release of the fuse-posix module might occur asynchronously wrt the release path of the rucio clients.

This issue is aimed at evaluating the possibility to use a double tagging schema for the rucio-fs container, in order to be able to express both the underlying rucio-clients version as well as the fuse posix module version.

This should require a minor update of the repo and would allow to trigger a rebuild of the rucio-fs container in case of fixes unrelated to the current rucio clients version.

We have a logic to apply patches inside the container before running rucio.
However, if those patches fail (for example, because the new version of rucio is not compatible with the patch), rucio is still run.

In most cases, this is an non-issue, because this results in a non-valid python file; so rucio fails to start.

Still, it will much better to explicitly fail the container startup when the patch command fails.

Currently, when using the daemons images with the default configuration they will try to connect to the atlas-test-mb brokers with an invalid certificate. That leads to a lot of warning messages on the brokers. Instead rather point them to localhost by default.

The use of RUCIO_ENABLE_LOGS and RUCIO_ENABLE_LOGFILE is inconsistent between the containers and the documentation. Switch to just using RUCIO_ENABLE_LOGS.

The multi-VO test script now uses the RUCIO_HOME environment variable to run the tests using config files in different locations (PR 3883).

Change the location of the cfg files in the dev container to match this, so that the m-VO test script can be run without needing to manually create the needed directory structure.

In order to allow the default Apache configuration for the server to be used at Fermilab in accordance with our security policies, I propose that TLS1.0/1.1 be disabled in the default configuration, with an option added to enable support for them if needed.

I would like to start the discussion on how the container could be made executable using Singularity in stead of Docker.
In the ESCAPE project, we did modify the container so it would run in user space in stead of as root (this is in itself probably a topic worth some discussion). I then changed it again so that not only the execution is in user space, but also the creation of the config file.

The repo is here: https://github.com/ESCAPE-WP2/rucio-client-container

It was pointed out to me by @mlassnig that the policy of the project is to prevent diverging releases. So I decided to open this as an issue upstream.

Before trying to apply the changed to this upstream repo I think it's wiser to first have a look at it together with you and hear your thoughts.

In production containers, the bin and lib directories are separate. Which is different from the developement env. So patches touching the bin/ files will fail.
I don't have an easy solution for this problem in mind

In case anyone else has this too, it seems recent RPMs add a /etc/httpd/conf.d/ssl.conf file by default which also listens on port 443 such that the auth server cannot.

I just add
RUN rm /etc/httpd/conf.d/ssl.conf
to my docker file which then allows the auth server to work. If this is a more general issue, we should probably move it to the Rucio-server/Dockerfile here

See rucio/probes#112 for a discussion

Would it be possible to remove the line VOLUME /etc/grid-security from Rucio Dockerfiles?

At IceCube we are running Rucio in a kubernetes cluster using modified containers from https://hub.docker.com/u/rucio. I'd like to use something like FROM rucio/rucio-server in my Dockerfiles but because of the line VOLUME /etc/grid-security the files I drop in /etc/grid-security when I build my container are not present when the container is deployed to kubernetes.

Making /etc/grid-security a volumeMount in kubernetes pods is not an attractive solution since we run several test instances of Rucio and using persistent storage for it would require some form of manual setup or clean-up. Populating /etc/grid-security when container is started also has obvious disadvantages. It would be much more convenient if our Rucio containers were as self-contained as possible.

The lines

RUN pip install -r /tmp/rucio/tools/pip-requires-client
RUN pip install -r /tmp/rucio/tools/pip-requires
RUN pip install -r /tmp/rucio/tools/pip-requires-test

in dev/Dockerfile point to files which have now been moved from tools/ to etc/.

FTS-cron takes the arguments of one VO and one VOMS/role, this doesn't allow for multi-VO setups which require multi-VOs and multiple voms

Adding a check for multi-vo=true in many of the proxy generations, and delegations.
Rucio can then look at the locations specified in the config for the proxy.
The difficulty is then locating the certs and keys for the proxies.

Is there a standardised place to place these? /opr/rucio/keys/, /opt/rucio/certs/
or for multi-VO should I specify a location within multi-VO?

I think the difficulty would then be to generate all the proxies and delegations as needed for continuous access. But this could be appended to the renew_fts_proxy.sh rather than override, so if many VOs were specified the script would be longer.

I updated to 1.22.3post1 and every request failed with this error

[Mon Apr 27 12:45:48.938509 2020] [:error] [pid 3816:tid 139660005021440] [client 158.39.48.13:34468] Embedded mode of mod_wsgi disabled by runtime configuration: /usr/lib/python2.7/site-packages/rucio/web/rest/authentication.py

The solution was to set in /etc/httpd/conf.d/rucio.conf:

WSGIRestrictEmbedded Off

This was set to On in this commit:

e7d510b

The UI containers contain the right version of the UI but the wrong version of Rucio. I don't know why yet

1.21.10 and post1 contains 1.22.0.dev2
1.21.12 contains 1.22.rc2

This is causing crashes because things are looking for token auth stuff on a DB that doesn't have the right schema.

I am looking for an image for the webui and am not finding any on Dockerhub (https://hub.docker.com/u/rucio). It would appear there has yet to be a release tag for the webui specifically. Is there a plan to make a release sometime soon? Thanks in advance.

Since rucio/webui#115 and rucio/webui#109, the environment variables used by the webui have been updated or new variables have been introduced. These changes should be propagated into the webui2 containers ( and helm charts rucio/helm-charts#124 )

Probably comes from this change
https://github.com/rucio/containers/pull/228/files#diff-c8f7697a6f459a8d862a2117344038dbb53406a79eaee8d54ea2b6a324271753R163

conflicting with the existing names. Removing - should be enough
https://github.com/rucio/containers/blob/master/.github/workflows/docker-auto-build.yml#L16

fts-rest-server requires rh-python36-mod_wsgi package which is available in the software collections repository.

The new webui follows the semantic versioning scheme. The major and minor values for the new webui will always match the major and minor versions of rucio releases that it can work with. The patch release for the new webui is independent of rucio releases.

As discussed with @bari12 , we have decided to make docker-auto-build support two independent release paths:

1. Standard Rucio Release: Such releases are tagged with a semantic version representing the rucio release. The Rucio WebUI is not built during this release
2. Rucio WebUI Release: These are WebUI only releases, and their tags follow the format webui-<semantic_version>

The docker-auto-build script must be updated to reflect this behavior

Add support for https://github.com/rucio/webui

For elastic/influx, the hermes2 daemon requires two new config items to be set, [hermes.elastic_endpoint] and [hermes.influxdb_endpoint] respectively (linked to elastic's /_bulk api endpoint and influx's /write endpoint respectively).

Due to rucio/rucio#6106, we build openssl 3.1 in daemon alma9 containers.

Openssl 3.1.1 was released recently (https://www.openssl.org/news/cl31.txt) and we should probably upgrade the spec file to use it instead of 3.1 here:
https://github.com/rucio/containers/blob/master/daemons/openssl.spec

I made a mistake changing the entrypoint in the wrong file causing the error:

Apply patch /patch/collection_replicas.patch
patch: **** Can't change to directory '' : No such file or directory

After upgrading from 1.29.0 -> 1.29.6, the API server now crashloops with:

IsADirectoryError: [Errno 21] Is a directory: '/var/log/rucio/trace'

The error goes away if I explicitly set:

tracedir: "/var/log/rucio/trace"

(which also requires the username/password to be set - blank values work)

Note that I do not have the trace server enabled.

I guess an easy fix would be to change the default value here so that it matches the stated default value in the Helm values.yaml ?

I'm not sure why this has just started in 1.29.6, however.

See rucio/rucio#6048 for details.

docker build of fts-cron/Dockerfile fails due to python2 syntax as seen here:
https://github.com/maany/containers/runs/3597211891?check_suite_focus=true#step:8:1222

can we have mod_gridsite (gridsite and libs rpms) in ruico/rucio-sserver container. I ran into this issue a while ago (I think it is related to support X509 proxy with VOMS).

The new webui no longer needs to request for x509 client certificates since rucio/rucio#6048.
As a result, its apache config needs to be cleanup up.

/start-daemon.sh: Permission denied

which makes me think the 1.23.11.post4 build picked up the python3-only change which went into containers.

When I set up the server I have to manually add this line in the apache config to enable the auth server:

WSGIScriptAlias /auth /usr/lib/python2.7/site-packages/rucio/web/rest/authentication.py

It would be good if this could be enabled through an env var.

In order to write Belle II specific tests, a new image including rucio.cfg with Belle II parameters is needed as well as a specific rse_repository.json that contains RSEs matching the RSE pattern (no underscore)

As described in rucio/rucio#4525 , fts transfers in the rucio-dev containers are failing with authentication timeout error as fts-rest-delegate uses python2 syntax
https://github.com/cern-fts/fts-rest/blob/develop/src/cli/fts-rest-delegate#L12

Adding python-setuptools, pip2 and requests allows the fts-rest-cli command to execute properly in
https://github.com/rucio/rucio/blob/master/tools/docker_activate_rses.sh#L61

I tried to use the latest docker image and it does not work:

rucio whoami
Traceback (most recent call last):
File "/usr/bin/rucio", line 64, in
from rucio.client.uploadclient import UploadClient
File "/usr/lib/python2.7/site-packages/rucio/client/uploadclient.py", line 41, in
from rucio.rse import rsemanager as rsemgr
File "/usr/lib/python2.7/site-packages/rucio/rse/init.py", line 94, in
from rucio.core.rse import get_rse_protocols, get_rse_id
ImportError: No module named core.rse