Do not source .bash_profile.acs too early

[dneise]

I just an into this issue:

Never source /alma/.../.bash_profile.acs before defining INTROOT and so on.

We source the .bash_profile.acs too early inside /etc/bashrc.

ACS-Docker-Image/Dockerfile

Line 58 in aad9907

echo "source $ACS_ROOT/ACSSW/config/.acs/.bash_profile.acs" >> /etc/bashrc

So any user, who logs in and

• creates INTROOT and ACSDATA (e.g. via getTemplateForDirectory)
• then exports INTROOT and ACSDATA
• and then sources the .bash_profile.acs again to make sure the exports take effect

Will end up with a horrible mess.
E.g. the env var ACS_TMP will not be redefined, since:

if [ X"$ACS_TMP" = X ] || [ X"$ACS_RETAIN" = X ]
then
	if [ "$OSYSTEM" = "$CYGWIN_VER" ]
	then
       ACS_TMP=$ACSDATA/tmp/`hostname`
	else
       ACS_TMP=$ACSDATA/tmp/`hostname -s`
	fi
fi

Which means .. if ACS_TMP already has a value (even when it it a wrong value) sourcing the bash_profile again will not reset ACS_TMP ... it will simply happily contain a wrong value forever.
This is highly surprising behaviour in my opinion, but we cannot fix it here.

However, we must not do this:

Instead I propose to create a symlink in /alma named .bash_profile.acs which points to $ACS_ROOT/ACSSW/config/.acs/.bash_profile.acs

[LeoBaro]

Hey @dneise and @emiliogq, I am trying out the AUG image. I pulled it with:
docker pull acscommunity/acs:2020.08.0-centos7

Then I started a container with an interactive shell and a volume: with:

mkdir shared_dir
docker run --rm -it \
   -u $UID \
   -e DISPLAY=$DISPLAY \
   -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
   -v $PWD/shared_dir:/shared_dir \
   -w /shared_dir \
   acscommunity/acs:2020.08.0-centos7

I saw that you put the following line
source /alma/ACS-2020AUG/ACSSW/config/.acs/.bash_profile.acs
at the bottom of the /etc/bashrc file, but the latter is not being executed when I start/enter the container. Indeed, If I try to execute it with:
source /etc/bashrc
I get the mess:

bash-4.2$ source /etc/bashrc
bash: history: //.bash_history: cannot create: Permission denied
/usr/bin/id: cannot find name for user ID 1116
whoami: cannot find name for user ID 1116
e34cc5f38e32 I have no name!:/shared_dir 3 >

If also tried to load INTROOT first, with:

INTROOT="/shared_dir/ACADA_ACS_INTROOT"
if [ ! -d $INTROOT ]; then
   mkdir $INTROOT
fi
export INTROOT="$INTROOT"

and then call the /etc/bashrc script but I get the same mess.

What I am doing wrong? Is there anywork around for this?

I'm using the following commands to setup the environment inside the virtual machine (with acs JUN)

source /alma/ACS-2020JUN/ACSSW/config/.acs/.bash_profile.acs

INTROOT="$HOME/ACADA_ACS_INTROOT"

if [ ! -d $INTROOT ]; then
   mkdir $INTROOT
fi
if [ -z "$(ls -A $INTROOT)" ]; then
   getTemplateForDirectory INTROOT $INTROOT
fi
export INTROOT="$INTROOT"
source /alma/ACS-2020JUN/ACSSW/config/.acs/.bash_profile.acs
export ACS_CDB="$HOME/Repos/sag-supervisor/sag_supervisor"

Thank you guys!

[dneise]

Hey @LeoBaro ! .. Nice to hear someone is using this!

So I think the problem here is this:

mkdir shared_dir
docker run --rm -it \
   -u $UID \           <--------  
   -e DISPLAY=$DISPLAY \
   -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
   -v $PWD/shared_dir:/shared_dir \
   -w /shared_dir \
   acscommunity/acs:2020.08.0-centos7

UID on your laptop/PC is most probably 1000 .. but in this docker image there is no user with UID 1000 ..
So it is like being logged into a machine as a user which does not exist :D.

---

From here you have unfortunately two ways ... it depends if you need the X-connection or not.

For X-connection keep reading:

(Without X .. it is easier ... I make another post for that)

So what I recommend (for now .. maybe we find a better way .. or maybe Emilio knows a better way) is this:
Please write your own little Docker file .. in which you "inherit" from acscommunity/acs:2020.08.0-centos7
Minimum example is this:

FROM acscommunity/acs:2020.08.0-centos7

ARG UID=1000
ARG GID=1000

RUN groupadd -g "$GID" almamgr && \
     useradd -g "$GID" -u "$UID" -d /home/almamgr -m -s /bin/bash almamgr && \
     passwd -d almamgr && \
     echo "source /alma/ACS-2020AUG/ACSSW/config/.acs/.bash_profile.acs" >> /home/almamgr/.bashrc

# You are still root here .. so feel free to yum install .. or otherwise install anything you need!

USER almamgr
SHELL ["/bin/bash", "-c"]

WORKDIR /home/almamgr

# you are almamgr user here .. so feel free to do anything you like to install as user .. not as root.
# Like maybe pip install .. or so.

Then please build your personal image by using this Dockerfile, e.g. like this:

docker build \
    --tag your_choice_maybe_sag \
    --build-arg "UID=$(id -u)" \
    --build-arg "GID=$(id -g)" \
    ./Dockerfile

This should only take few seconds .. and it does not need to be repeated very often .. only when you need to instal new dependencies.

---

Then start a container from your own personal image like this:

mkdir shared_dir
docker run --rm -it \
   -e DISPLAY=$DISPLAY \
   -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
   -v $PWD/shared_dir:/shared_dir \
   -w /shared_dir \
   sag:latest

You should get a prompt like this:

a4f9038f1c5f almamgr:/shared_dir 1 >

Please then try: acscommandcenter .. to verify the X-connection works well.

[dneise]

If you do not need an X connection, just do:

mkdir shared_dir
docker run --rm -it \
   -v $PWD/shared_dir:/shared_dir \
   -w /shared_dir \
   acscommunity/acs:2020.08.0-centos7

Then you should get:

23265c58b62f root:/shared_dir 1 > acsStart     

You are root in that container and can install and do whatever you like ... but getting an X-connection is somehow tricky.... Sorry.

[LeoBaro]

Amazing support!

Indeed the
-u $UID \ <--------
was the issue. Now I can "see" the acs commands inside the container.

I'll try the X-connection and I'll let you know.

[dneise]

I think we have to put some more docu into the README.md of this repo .. thanks for the question .. sometimes I know I did not document correctly ... but I simply am too lazy to write it down ...

[LeoBaro]

Yeah, I can relate.

Anyway, I built the "custom" image but when I try to start the acs GUI I get an error.

I run the container with:

mkdir -p pshared_dir

docker run --rm -it \
   -e DISPLAY=$DISPLAY \
   -v /tmp/.X11-unix:/tmp/.X11-unix:rw \
   -v $PWD/shared_dir:/shared_dir \
   -w /shared_dir \
   2020.08.0-centos7-sag:latest

Then:

ad45b04c1ca4 root:/shared_dir 1 > acscommandcenter
 --noDirectory --noexport --endorsed -D ACS.root=/alma/ACS-2020AUG/ACSSW -D ACS.cdbroot=/alma/ACS-2020AUG/acsdata/config/defaultCDB -- alma.acs.commandcenter.CommandCenter
2020-12-03T14:59:48.593 INFO [acsStartJava] Starting Java application: alma.acs.commandcenter.CommandCenter
2020-12-03T14:59:48.639 INFO [acsStartJava] Using endorsed jar files in: /alma/ACS-2020AUG/ACSSW/lib/endorsed:/alma/ACS-2020AUG/JacORB/lib/endorsed:
OpenJDK 64-Bit Server VM warning: Archived non-system classes are disabled because the java.system.class.loader property is specified (value = "alma.acs.classloading.AcsSystemClassLoader"). To use archived non-system classes, this property must be not be set
2020-12-03T14:59:49.966 DELOUSE [alma.acs.logging.config.LogConfig] Logging configuration has been initialized, but not from CDB settings.
2020-12-03T14:59:50.037 FINER [alma.acs.logging] Changed processName='null' to 'alma.acs.commandcenter' and updated logger names.
2020-12-03T14:59:50.046 FINER [alma.acs.logging] Changed processName='alma.acs.commandcenter' to 'alma.acs.commandcenter.app' and updated logger names.
2020-12-03T14:59:50.057 FINER [alma.acs.logging] Changed processName='alma.acs.commandcenter.app' to 'alma.acs.commandcenter.engine' and updated logger names.
Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server using 'localhost:10.0' as the value of the DISPLAY variable.
        at java.desktop/sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
        at java.desktop/sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:102)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.desktop/sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:61)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:315)
        at java.desktop/java.awt.GraphicsEnvironment$LocalGE.createGE(GraphicsEnvironment.java:101)
        at java.desktop/java.awt.GraphicsEnvironment$LocalGE.<clinit>(GraphicsEnvironment.java:83)
        at java.desktop/java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:129)
        at java.desktop/javax.swing.RepaintManager.<clinit>(RepaintManager.java:240)
        at java.desktop/javax.swing.JComponent.repaint(JComponent.java:4835)
        at java.desktop/java.awt.Component.repaint(Component.java:3393)
        at java.desktop/javax.swing.AbstractButton.setModel(AbstractButton.java:1730)
        at java.desktop/javax.swing.JButton.<init>(JButton.java:128)
        at java.desktop/javax.swing.JButton.<init>(JButton.java:85)
        at alma.acs.commandcenter.gui.CommandCenterGui.<clinit>(CommandCenterGui.java:84)
        at alma.acs.commandcenter.app.CommandCenterLogic.prepare(CommandCenterLogic.java:121)
        at alma.acs.commandcenter.CommandCenter.main(CommandCenter.java:131)

Some additional informations:

• My local machine is a laptop. The docker deamon runs on a remote machine. I tried to connect to the remote machine using:
  • Windows10 + Putty
  • CentOs7 + ssh -X
    In both cases I get the same error.
• The remote machine runs CentOS7. The docker daemon is running here.
• $DISPLAY=localhost:10.0
• I tried to change the value of the of the DISPLAY variabile, e.g. export DISPLAY=localhost:0 (but IDK what Im doing cause I dont know X11).
• I tried a simple matplotlib example for a remote plot visualization and it works.

Do you have any ideas? Thanks in advance!

EDIT:
So, the configuration is:
LOCAL <==X11==> REMOTE <==X11==> CONTAINER

I haven't tried this yet:
LOCAL <==X11==> CONTAINER

But if the latter configuration works, I can conclude that the issue is not arising from the docker image. Unfortunatly, I can't try it immediatly

[dneise]

Hey Leonardo ..

So, the configuration is:
LOCAL <==X11==> REMOTE <==X11==> CONTAINER
I haven't tried this yet:
LOCAL <==X11==> CONTAINER

Why is your setup so complicated? Is it personal choice? Or are you forced to work like this?

So .. I personally am really really bad, with all this X-forwarding through SSH .. Either it works right away Or I have no idea what is going on.

I use the latter configuration for development and playing around. My laptop is just an Ubuntu .. and I installed docker on it using some manual from the web ..

However, when I am executing tests on a remote server .. (for example when doing unit tests in a continuous integration setup) ... I do not use X-forwarding anymore.

I understand there might be use-cases .. where your Remote is very powerful and you want to execute performance tests on that, while on your laptop that would not make sense ... and for debugging and playing around you want still graphical access to the remote. Is that your usecase?

I guess I personally would in that case actually install ACS2020.8 directly onto the remote ... since in your case it already has CentOS7 installed. Is that an option?
So on your laptop ... development using docker ... on the remote .. ACS on the bare-metal.

[dneise]

If you are working with matplotlib a lot on headless machines, I would recommend to set the backend to Agg or so .. potentially using the environment variable MPLBACKEND like so:

export MPLBACKEND=qt5agg

This way you the python code stays identical .. but on a headless machine with MPLBACKEND set you get no problems .. but on your laptop you get the plots.

More here:
https://matplotlib.org/3.2.1/tutorials/introductory/usage.html#selecting-a-backend

[LeoBaro]

Hey Dominik, sorry for the late response.

Why is your setup so complicated? Is it personal choice? Or are you forced to work like this?

I would say it is a personal choice. We (inaf team) develop software in a remote shared machine running CentOs7. Also, yes, it's a really powerful machine, but performance tests are not my use case right now.
Yes, I can choose to work in localhost, I have double OS (centos7,windows10) on my laptop...I was always booting CentOs7 in the beginning...but the battery consumption is huge..and the user interface is not graet...so after some months I switched to Windows10 (but I always develop under Linux).
So, if I want to work in localhost I should switch back again to CentOs7, synch the environment, clean the filesystem, etc...I am too lazy right now to do so :)

I use the latter configuration for development and playing around. My laptop is just an Ubuntu .. and I installed docker on it using some manual from the web ..

I have another laptop with Ubuntu 18.04, I installed docker, pulled the acscontainer, built the "custom" recipe and it works: I can see the ACS GUI just fine :)

I guess I personally would in that case actually install ACS2020.8 directly onto the remote ... since in your case it already has CentOS7 installed. Is that an option?

Nope, the remote is a shared machine, I should not install software as root. Also, I suppose that I should compile acs from scratch (installing the required dependencies). I dont want to do that. Also, I like docker :)

If you are working with matplotlib a lot on headless machines

Nope, I am not working with matplotlib. I just execute a matplotlib script in the remote machine (outside acs container) to check if the X11 forwarding was working.

The following schema, summarize the tests I performed on X11 forwarding:

LOCAL (ubuntu) <=> CONTAINER (centOS7) (it works! I can see the ACS GUI)
LOCAL (ubuntu) <=> REMOTE (centOS7) (it works! I can see matplolib plot, xterm, etc..)
LOCAL (centOS7) <=> REMOTE (centOS7) (it works! I can see matplolib plot, xterm, etc..)
LOCAL (ubuntu) <=> REMOTE (centOS7)<=> CONTAINER (centOS7) (still not working)

As you can see, the issue arise when a try to do a "3way forwarding" of X11.

Since X11 is quite complicated and I know little about it, I can't proceed with a try&error approach. In the next days, I'll try to read about X11 and I'll try to fix the issue.

I'll let you know!

[dneise]

So, if I want to work in localhost I should switch back again to CentOs7, synch the environment, clean the filesystem, etc...I am too lazy right now to do so :)

I can totally understand ... I used a dual boot .... many years ago .. and after some time .. I basically only used one of the OS .. and totally ignored the other.

[dneise]

Nope, the remote is a shared machine, I should not install software as root. Also, I suppose that I should compile acs from scratch (installing the required dependencies). I don't want to do that. Also, I like docker :)

Ah I see ... makes sense to me .. I also like docker. Just ... if you ever want to .. or need to install ACS from the sources, actually this project here was started to provide help in that regard as well:

In contrast to the docker image provided by DESY for ACADA .. we do not use ACS RPMs in the creation of this image. Instead we clone directly from the ACS repo and build it from the sources.

So the Dockerfile should be a useful "step-by-step" guide on what the requirements are and how to install ACS...
(Again .. just in case you ever are forced to do it...)

[dneise]

I hope this might help

https://unix.stackexchange.com/questions/403424/x11-forwarding-from-a-docker-container-in-remote-server/416769

[LeoBaro]

So the Dockerfile should be a useful "step-by-step" guide on what the requirements are and how to install ACS...

Got it, thanks!

I hope this might help
https://unix.stackexchange.com/questions/403424/x11-forwarding-from-a-docker-container-in-remote-server/416769

Nice! It seems very promising. I'll try it out as soon as possible! Thanks!

[dneise]

No worries .. much luck