rucio / containers Goto Github PK
View Code? Open in Web Editor NEWContainers for Rucio
License: Apache License 2.0
Containers for Rucio
License: Apache License 2.0
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).
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.
.bashrc does j2 rucio.cfg.j2 > /opt/rucio/etc/rucio.cfg
but rucio.cfg.j2 is in / and not in /root
call with absolute path:
j2 /rucio.cfg.j2 > /opt/rucio/etc/rucio.cfg
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.
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:
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.
fts-rest-server
requires rh-python36-mod_wsgi package which is available in the software collections repository.
See rucio/probes#112 for a discussion
/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.
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
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?
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.
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:
cert
and key
filevoms-proxy-init
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
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).
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.
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.
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.
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 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
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.
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
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.
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 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
Add support for https://github.com/rucio/webui
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
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.
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
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/
.
Usable by any Community, config can be specified (or container included in a wrapper container)
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:
.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.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.
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)
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 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.
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.
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 )
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.
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.
See rucio/rucio#6048 for details.
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?
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.
This is a setting CMS needs
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
Using the container for testing RSEs, the CERN CA was not recognized.
Install CERN CA in the Dockerfile and thus update the image.
CERN certificates are trusted.
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).
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.
Starting here
containers/daemons/rucio.cfg.j2
Line 86 in 18a0805
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.
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:
webui-<semantic_version>
The docker-auto-build script must be updated to reflect this behavior
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.