diff --git a/2024.8.1gui/.buildinfo b/2024.8.1gui/.buildinfo
new file mode 100644
index 0000000..dbd0560
--- /dev/null
+++ b/2024.8.1gui/.buildinfo
@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: 9b5ca99a40dface56730f10febf94955
+tags: 645f666f9bcd5a90fca523b33c5a78b7
diff --git a/2024.8.1gui/.doctrees/environment.pickle b/2024.8.1gui/.doctrees/environment.pickle
new file mode 100644
index 0000000..0a7ea38
Binary files /dev/null and b/2024.8.1gui/.doctrees/environment.pickle differ
diff --git a/2024.8.1gui/.doctrees/explanations.doctree b/2024.8.1gui/.doctrees/explanations.doctree
new file mode 100644
index 0000000..0acdd93
Binary files /dev/null and b/2024.8.1gui/.doctrees/explanations.doctree differ
diff --git a/2024.8.1gui/.doctrees/explanations/differences.doctree b/2024.8.1gui/.doctrees/explanations/differences.doctree
new file mode 100644
index 0000000..f93a94a
Binary files /dev/null and b/2024.8.1gui/.doctrees/explanations/differences.doctree differ
diff --git a/2024.8.1gui/.doctrees/explanations/how_it_works.doctree b/2024.8.1gui/.doctrees/explanations/how_it_works.doctree
new file mode 100644
index 0000000..28e7d7d
Binary files /dev/null and b/2024.8.1gui/.doctrees/explanations/how_it_works.doctree differ
diff --git a/2024.8.1gui/.doctrees/explanations/why_dev_c7.doctree b/2024.8.1gui/.doctrees/explanations/why_dev_c7.doctree
new file mode 100644
index 0000000..69ed13f
Binary files /dev/null and b/2024.8.1gui/.doctrees/explanations/why_dev_c7.doctree differ
diff --git a/2024.8.1gui/.doctrees/how-to.doctree b/2024.8.1gui/.doctrees/how-to.doctree
new file mode 100644
index 0000000..83bc767
Binary files /dev/null and b/2024.8.1gui/.doctrees/how-to.doctree differ
diff --git a/2024.8.1gui/.doctrees/how-to/containers.doctree b/2024.8.1gui/.doctrees/how-to/containers.doctree
new file mode 100644
index 0000000..209b9cf
Binary files /dev/null and b/2024.8.1gui/.doctrees/how-to/containers.doctree differ
diff --git a/2024.8.1gui/.doctrees/how-to/deriving.doctree b/2024.8.1gui/.doctrees/how-to/deriving.doctree
new file mode 100644
index 0000000..bc7ed5b
Binary files /dev/null and b/2024.8.1gui/.doctrees/how-to/deriving.doctree differ
diff --git a/2024.8.1gui/.doctrees/how-to/podman.doctree b/2024.8.1gui/.doctrees/how-to/podman.doctree
new file mode 100644
index 0000000..2d37ef0
Binary files /dev/null and b/2024.8.1gui/.doctrees/how-to/podman.doctree differ
diff --git a/2024.8.1gui/.doctrees/how-to/troubleshooting.doctree b/2024.8.1gui/.doctrees/how-to/troubleshooting.doctree
new file mode 100644
index 0000000..37caf14
Binary files /dev/null and b/2024.8.1gui/.doctrees/how-to/troubleshooting.doctree differ
diff --git a/2024.8.1gui/.doctrees/index.doctree b/2024.8.1gui/.doctrees/index.doctree
new file mode 100644
index 0000000..c964d65
Binary files /dev/null and b/2024.8.1gui/.doctrees/index.doctree differ
diff --git a/2024.8.1gui/.doctrees/reference.doctree b/2024.8.1gui/.doctrees/reference.doctree
new file mode 100644
index 0000000..8b1ce98
Binary files /dev/null and b/2024.8.1gui/.doctrees/reference.doctree differ
diff --git a/2024.8.1gui/.doctrees/reference/contributing.doctree b/2024.8.1gui/.doctrees/reference/contributing.doctree
new file mode 100644
index 0000000..848505e
Binary files /dev/null and b/2024.8.1gui/.doctrees/reference/contributing.doctree differ
diff --git a/2024.8.1gui/.doctrees/tutorials.doctree b/2024.8.1gui/.doctrees/tutorials.doctree
new file mode 100644
index 0000000..627d1fc
Binary files /dev/null and b/2024.8.1gui/.doctrees/tutorials.doctree differ
diff --git a/2024.8.1gui/.doctrees/tutorials/continue.doctree b/2024.8.1gui/.doctrees/tutorials/continue.doctree
new file mode 100644
index 0000000..ce4a7bb
Binary files /dev/null and b/2024.8.1gui/.doctrees/tutorials/continue.doctree differ
diff --git a/2024.8.1gui/.doctrees/tutorials/prompt.doctree b/2024.8.1gui/.doctrees/tutorials/prompt.doctree
new file mode 100644
index 0000000..2ca06a6
Binary files /dev/null and b/2024.8.1gui/.doctrees/tutorials/prompt.doctree differ
diff --git a/2024.8.1gui/.doctrees/tutorials/start.doctree b/2024.8.1gui/.doctrees/tutorials/start.doctree
new file mode 100644
index 0000000..682ebed
Binary files /dev/null and b/2024.8.1gui/.doctrees/tutorials/start.doctree differ
diff --git a/2024.8.1gui/.doctrees/tutorials/vscode.doctree b/2024.8.1gui/.doctrees/tutorials/vscode.doctree
new file mode 100644
index 0000000..6ce8a22
Binary files /dev/null and b/2024.8.1gui/.doctrees/tutorials/vscode.doctree differ
diff --git a/2024.8.1gui/_images/button.png b/2024.8.1gui/_images/button.png
new file mode 100644
index 0000000..dc17cd8
Binary files /dev/null and b/2024.8.1gui/_images/button.png differ
diff --git a/2024.8.1gui/_sources/explanations.rst.txt b/2024.8.1gui/_sources/explanations.rst.txt
new file mode 100644
index 0000000..888750e
--- /dev/null
+++ b/2024.8.1gui/_sources/explanations.rst.txt
@@ -0,0 +1,13 @@
+:orphan:
+
+Explanations
+============
+
+Explanation of how the library works and why it works that way.
+
+.. toctree::
+ :caption: Explanations
+
+ explanations/how_it_works
+ explanations/differences
+ explanations/why_dev_c7
diff --git a/2024.8.1gui/_sources/explanations/differences.rst.txt b/2024.8.1gui/_sources/explanations/differences.rst.txt
new file mode 100644
index 0000000..97e3aa1
--- /dev/null
+++ b/2024.8.1gui/_sources/explanations/differences.rst.txt
@@ -0,0 +1,76 @@
+RHEL7 native vs dev-c7
+======================
+
+The ``dev-c7`` container attempts to emulate the same environment and file systems
+that a DLS RHEL7 workstation sees. Inevitably there are a few differences
+which are documented on this page.
+
+Centos vs RHEL7
+---------------
+
+This container is based upon a Centos 7 image rather than a RHEL7 image
+because of complicated licensing for RHEL7 containers. In almost all
+respects this should make little difference because both OSes have the
+same packages available to them.
+
+Any code that queries the OS name will get a different answer. This affects
+dls-release.py because it uses the OS name to choose the default RHEL version
+to release to. However this has been patched to accept Centos 7 to mean
+a release for RHEL7.
+
+We are not aware of any other DLS tools affected by this at present.
+
+User IDs
+--------
+
+Inside of the container there are only two interactive users. Your own user
+and root. ``c7`` uses ``--userns=keep-id`` so that your same user id
+is used inside and outside of the container.
+
+Hence the container is able to see the file ownership of mounted file systems
+as long as they belong to root or to you.
+
+No other users are known to it and when listing the contents of
+a shared directory any files that have unknown user group membership will
+show up as uid or gid 65534.
+
+This does not affect your ability to write to files that have permission for
+your secondary group. So files with group write for the dcs account will
+be writeable. Unfortunately you will not be able to tell they are writeable
+by using ls -l because the dcs group is unknown inside the container.
+
+e.g.
+
+.. raw:: html
+
+
The dev-c7 container attempts to emulate the same environment and file systems
+that a DLS RHEL7 workstation sees. Inevitably there are a few differences
+which are documented on this page.
This container is based upon a Centos 7 image rather than a RHEL7 image
+because of complicated licensing for RHEL7 containers. In almost all
+respects this should make little difference because both OSes have the
+same packages available to them.
+
Any code that queries the OS name will get a different answer. This affects
+dls-release.py because it uses the OS name to choose the default RHEL version
+to release to. However this has been patched to accept Centos 7 to mean
+a release for RHEL7.
+
We are not aware of any other DLS tools affected by this at present.
Inside of the container there are only two interactive users. Your own user
+and root. c7 uses --userns=keep-id so that your same user id
+is used inside and outside of the container.
+
Hence the container is able to see the file ownership of mounted file systems
+as long as they belong to root or to you.
+
No other users are known to it and when listing the contents of
+a shared directory any files that have unknown user group membership will
+show up as uid or gid 65534.
+
This does not affect your ability to write to files that have permission for
+your secondary group. So files with group write for the dcs account will
+be writeable. Unfortunately you will not be able to tell they are writeable
+by using ls -l because the dcs group is unknown inside the container.
By default a container runs a single process (of id 1) and terminates when
+that process terminates. c7 launches a background process
+that does nothing as process 1 and
+then executes any number of interactive shells inside of it.
+
Although you
+have the filesystem of a Centos 7 workstation inside the
+container, by design it is not an entire virtual machine.
+
Therefore none of the usual services will be running inside of the container.
+For example any apps that wish to communicate over DBus will not find the DBus
+service.
+
So far this has not affected any DLS development workflow. It may be possible
+to launch services inside the container if they prove to be essential.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Other Versions
+ 2024.8.1gui
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/2024.8.1gui/explanations/how_it_works.html b/2024.8.1gui/explanations/how_it_works.html
new file mode 100644
index 0000000..082e45f
--- /dev/null
+++ b/2024.8.1gui/explanations/how_it_works.html
@@ -0,0 +1,258 @@
+
+
+
+
+
+
+ How the dev-c7 Container Works — dev-c7 2024.8.1gui
+ documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Podman is a daemonless, rootless container engine developed by RedHat,
+designed as an alternative to Docker.
+
Using containers allows us to package up all the dependencies of an
+application and execute it in an isolated fashion.
+
In the case of dev-c7 we use podman to package up everything required
+by the DLS controls developer workflow. This is essentially a set
+of system libraries and tools plus mounted shared file systems such
+as /dls_sw and /home.
A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.
+
+
An image is a layered snapshot of a file system. Images adhere to the
+Open Container Initiative
+standard and therefore images built by Docker and Podman are interchangeable.
+
Images are stored in a container registry such as DockerHub or GitHub Container
+Registry https://ghcr.io. The image for dev-c7 is stored alongside its source
+code here:
The c7 script uses podmanrun to create a container based on
+the above image. The container is an isolated execution environment with
+its own file system based upon the above image. Any changes to the
+file system are added in a layered fashion.
+
The container’s file system changes are lost when the container is deleted.
+However with c7 we arrange for that to happen only if
+the user explicitly deletes dev-c7.
The script c7 launches a container in the background using
+podman. It then executes an interactive bash shell inside of that
+container.
+
This means that when you exit the bash prompt the container continues to
+run in the background.
+
Further invocations of c7 will execute further interactive bash
+shells in the same container.
+
If the container is stopped (via podmanstopdev-c7 or due to a host
+reboot) then the next invocation of c7 will detect this and
+restart it.
+
Because of this the dev-c7 container is not ephemeral like most containers,
+it persists changes that you make in the OS until it is explicitly deleted.
The system partition in which the operating system is installed resides
+inside the container. However c7 mounts a number of host and
+shared file systems. This is how the container is made to look very
+similar to a RHEL7 workstation. The mounted file systems are as follows:
c7 executes bash-l in order to create an interactive
+shell in the container. The following features make this work:
+
+
The home directories folder /home is mounted
+
the HOME environment variable is passed into the container
+
the user namespace is mapped into the container namespace
+
+
The above points mean that bash is able to run .bash_profile from your
+home directory under your account. Hence all the usual DLS profile
+features are loaded.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Other Versions
+ 2024.8.1gui
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/2024.8.1gui/explanations/why_dev_c7.html b/2024.8.1gui/explanations/why_dev_c7.html
new file mode 100644
index 0000000..2df713c
--- /dev/null
+++ b/2024.8.1gui/explanations/why_dev_c7.html
@@ -0,0 +1,186 @@
+
+
+
+
+
+
+ Purpose of the dev-c7 Container — dev-c7 2024.8.1gui
+ documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This project allows controls developers to continue to work on IOCs and tools
+built for RHEL7, while at the same time allowing the DLS wide upgrade to
+RHEL8 to continue.
Previously the task of upgrading from RHEL6 to RHEL7 proved to be quite
+complicated and took several years to finalize.
+
Hence this project is a stopgap so that we can use effort to work on replacing
+our
+tools and deployment process with one based on containers and Kubernetes.
+Some details of the epics-containers approach are documented here
+https://github.com/epics-containers.
+
With the new approach under development it would be a waste of effort to
+port our legacy toolchain to RHEL8 only to replace it shortly afterward.
+The container based approach decouples the tools and IOCs from the
+host operating system so any future OS upgrades should be far
+smoother.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Other Versions
+ 2024.8.1gui
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/2024.8.1gui/genindex.html b/2024.8.1gui/genindex.html
new file mode 100644
index 0000000..36a61e5
--- /dev/null
+++ b/2024.8.1gui/genindex.html
@@ -0,0 +1,165 @@
+
+
+
+
+
+ Index — dev-c7 2024.8.1gui
+ documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
You can see which Containers are running on your system with:
+
podmanps-a
+
+
+
The -a means it will also show stopped containers.
+
You can see what Images are cached on your system with:
+
podmanimages
+
+
+
Images are usually cached from a container registry like ghcr.io. They can
+usually be deleted without any consequence except waiting for the download
+next time you launch a container that uses them.
The dev-c7 container image is built from the container context folder
+dev-c7/docker.
+The context contains a Dockerfile which details the steps to build the
+container image.
+
To experiment with making additions to the dev-c7 project, first clone
+the project and do a test build of the container:
build-dev-c7 will create a container image with the tag
+ghcr.io/dls-controls/dev-c7. This is the same tag that c7
+uses so it will launch a container based on your newly built image.
+
+
Note
+
You will likely already have a dev-c7 container running and you must delete
+that before your new one will launch. Otherwise the launch script will
+just open a new bash session in the existing container.
+To do this see Deleting the container.
+
+
Now you are ready to make any changes you wish to the Dockerfile and add
+any additional files to the context (i.e. in the dev-c7/docker folder).
+
Below is the current Dockerfile, read on for an explanation of the
+commands used.
+
# Dockerfile for getting DLS RHEL7 dev environment working in a container
+# hosted on RHEL8
+#
+# This is a stopgap so that we can use effort to promote the
+# kubernetes model https://github.com/dls-controls instead of spending
+# effort in rebuilding our toolchain for RHEL8
+
+FROMcentos:7
+
+# environment
+ENVLANG=en_US.UTF-8
+ENVLC_ALL=en_US.UTF-8
+ENVLC_CTYPE=en_US.UTF-8
+ENVMODULEPATH=/etc/scl/modulefiles:/etc/scl/modulefiles:/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles:/dls_sw/apps/Modules/modulefiles:/dls_sw/etc/modulefiles:/home/hgv27681/privatemodules:/dls_sw/prod/tools/RHEL8-x86_64/defaults/modulefiles
+
+# make QT not complain
+ENVQT_X11_NO_MITSHM=1
+ENVLIBGL_ALWAYS_INDIRECT=1
+
+# switch to the vault for centos packages!
+RUNsed-is/mirror.centos.org/vault.centos.org/g/etc/yum.repos.d/*.repo&&\
+sed-is/^#.*baseurl=http/baseurl=http/g/etc/yum.repos.d/*.repo&&\
+sed-is/^mirrorlist=http/#mirrorlist=http/g/etc/yum.repos.d/*.repo
+
+RUNyumupdate-y&&\
+#devtoolsandlibraries
+yumgroupinstall-y"Development Tools"&&\
+yuminstall-yglibc.i686redhat-lsb-corelibusbxnet-snmp-libsenvironment-modulesgit2unet-toolsscreencmakelapack-develreadline-develpcre-develboost-devellibpcap-develnumactl-libsvimdbus-x11bind-utilslibssh2-develxorg-x11-server-Xvfb\
+#edmdependencies
+epel-releasegiflib-devellibXmu-devellibpng-devellibXtst-develzlib-develxorg-x11-proto-develmotif-devellibX11-devellibXp-devellibXpm-devellibtirpc-devel\
+#areaDetectordependencies
+libxml2-devellibjpeg-turbo-devellibtiff-devel\
+#Odindependencies
+hdf5-develzeromq-devellibrdkafka-devel\
+#QT4dependencies
+pyqt4-develPackageKit-gtk3-modulelibcanberra-gtk2mesa-dri-drivers.x86_64xcb-utilxcb-util-devellibxcb.x86_64libxkbcommon-x11\
+#dls-remote-desktop-support
+xfreerdpzenity\
+#usefultools
+sudomeldtkdejavu-sans-mono-fontsgnome-terminalxtermxmessageevinceeogfirefoxjavaopenldap-clients&&\
+#Thesepackagesarenotfoundintheinitialinstallsotryagain
+yuminstall-yzeromq-develgit2umeld&&\
+#cleanupcaches
+yumcleanall&&\
+#nastyhacktoavoidoverlayfilesystemproblemswith--userns=keep-id
+#hopefullycanberemovedwhenthisPRisreleasedanddeployedatDLS
+#https://github.com/containers/fuse-overlayfs/pull/381
+rm-fr/var/lib/yum/yumdb/*
+
+# full sudo rights inside the container
+COPY/sudoers/etc/sudoers
+
+# Workaround to ensure all locales are available
+RUNsed-i"/override_install_langs=en_US/d"/etc/yum.conf
+RUNyumreinstall-yglibc-common
+
+# set container time to BST
+RUNln-sf/usr/share/zoneinfo/Europe/London/etc/localtime
+
+# latest git from the endpoint repo https://computingforgeeks.com/install-git-2-on-centos-7/
+RUNyumremove-ygitgit-core&&\
+#libcurl-develforgit-remote-https
+yum-yinstalllibcurl-devel&&\
+yum-yinstallhttps://packages.endpointdev.com/rhel/7/os/x86_64/endpoint-repo.x86_64.rpm&&\
+yum-yinstallgitgit-core
+
+# change the nobody account and group IDs to match RedHat
+RUNsed-i's/99:99/65534:65534/'/etc/passwd&&\
+sed-i's/:99:/:65534:/'/etc/group
+
+
+
The base image is selected with the FROM command this defines what the
+container file system looks like initially. Every command in the Dockerfile
+then adds a layer of change to the container image.
+
The majority of the Dockerfile for dev-c7 is using yum install to get
+packages installed into the OS. Yum is executed via the RUN command.
+Note that the RUN command takes a single shell command line input.
+
+
Note
+
It is
+common in Dockerfiles to use &&\ to string multiple commands together
+in a single RUN. The reason to do this is to minimize the number
+of layers
+in the container image. In particular, if you want to clean up temporary
+files, it must be done in the same layer they were created or it will not
+reduce the size of the resulting image (because there is a layer with the
+temp files and then another layer that removes them).
+
+
The RUN command may execute any command that is available inside the
+container. For example the above uses a single RUN to get the source for
+a new version of git and compile it.
+
Another command in this Dockerfile is ENV which simply sets an environment
+variable for the processes the container launches.
+
The COPY command allows you to supply files from the context
+(dev-c7/docker folder in this case).
+Note that the path / is the root of the context. You can only
+copy files from inside the context, thus the context folder holds the entire
+definition of the image generated.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Other Versions
+ 2024.8.1gui
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/2024.8.1gui/how-to/deriving.html b/2024.8.1gui/how-to/deriving.html
new file mode 100644
index 0000000..28b53d8
--- /dev/null
+++ b/2024.8.1gui/how-to/deriving.html
@@ -0,0 +1,206 @@
+
+
+
+
+
+
+ Derive your own container image — dev-c7 2024.8.1gui
+ documentation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Each developer is free to derive their own container image if they have
+specific requirements e.g.
+
+
Additional system libraries
+
Additional command line or GUI tools
+
Any other OS configuration that they prefer
+
+
+
Note
+
If the changes you need are likely to be useful to all developers then
+you should consider contributing to the base image for dev-c7.
+See Contributing
+
+
To make your own derived container.
+
+
Create a folder (this is your container context folder)
+
Make a Dockerfile in that folder
+
Drop in any files that you want to copy into the container
+
cd into the folder
+
podmanbuild--tagmy-dev-c7.
+
c7 -i my-dev-c7
+
+
Below is an example Dockerfile derived from dev-c7 that adds a package with
+yum, sets an environment variable and copies a script into /usr/bin. Note
+that the build is running as root inside the container so it is allowed
+to write to a system folder.
+
FROMghcr.io/dls-controls/dev-c7:latest
+
+# dev tools and libraries
+RUNyumupdate-y&&\
+yuminstall-ymy-package
+
+ENVMY_VAR="useful info"
+
+COPY/my-useful-file.sh/usr/bin
+
Please ensure you are using a RHEL8 workstation before continuing.
+
+
Previous users of podman may need to update their podman settings to
+support features required by dev-c7.
+
+
Note
+
Updating your container filesystem may require deleting all images,
+containers and volumes in your cache. Make sure you are able to
+recreate all assets you need before continuing
+
+
To update simply run the script /dls_sw/apps/setup-podman/setup.sh.
+If your podman config is already up to date then this will have no effect,
+if it needs to delete your cache it will warn you before doing so.
+
If you do not have sudo rm permission on your workstation you will be
+required to have an administrator run the script on your behalf.
If you want to use edm then you will need to have the local fonts on your
+host machine. These will eventually be provided by default on the standard DLS
+RHEL8 workstation. However, early adopters will need to install these
+themselves.
When building the container for the first time, you may come across the following:
+`
+Error:writingblob:addinglayerwithblob
+"sha256:0b2dc63a68b9b80b6e261e0c71119894a739d353f8263d6b2f1394c66a45f5af":ApplyLayerexitstatus1stdout:
+stderr:potentiallyinsufficientUIDsorGIDsavailableinusernamespace(requested0:54for/run/lock/lockdev):
+Check/etc/subuidand/etc/subgid:lchown/run/lock/lockdev:invalidargument
+`
+
Rootless Podman uses a pause process to preserve the unprivileged namespaces,
+which locks down the user files /etc/subuid and /etc/subgid.
+The following command will stop the pause process and release the files for
+editing:
Then you probably have an empty /etc/subuid file. This is automatically updated by
+cfengine at 11AM every day. If your workstation was recently built then you may
+need to wait until the next 11AM !!
Contributions and issues are most welcome! All issues and pull requests are
+handled through GitHub. Also, please check for any existing issues before
+filing a new one. If you have a great idea but it involves big changes, please
+file a ticket before making a pull request! We want to make sure you don’t spend
+your time coding something that might not fit the scope of the project.
The image can be made locally with the script build-dec-c7. The
+resulting image will be placed in the local cache with the tag
+ghcr.io/dls-controls/dev-c7:latest.
+
Since this is the default tag that run-dev-c7 uses you can now use it
+launch and try out the new container image.
+
At present there are no tests to prove that the resulting image works. TBA.
To see optional parameters, run the launch script with -h:
+
$ c7 -h
+
+usage: c7 [options]
+
+Launches a developer container that simulates a DLS RHEL7 workstation.
+
+Options:
+
+ -h show this help
+ -l Enable logging
+ -p pull an updated version of the image first
+ -i image specify the container image (default: ghcr.io/dls-controls/dev-c7)
+ -v version specify the image version (default: latest)
+ -s host set a hostname for your container (default: pc0116.cs.diamond.ac.uk)
+ -d delete previous container and start afresh
+ -n run in podman virtual network instead of the host network
+ -c command run a command in the container (must be last option)
+ -I Install .devcontainer/devcontainer.json in the current directory for vscode
+ -g enable X11 GUI for containers launched via ssh (only required with -r)
+ -r run as root
+
The default behaviour is that c7 will use the latest container version in the
+registry on first invocation. When it launches and attaches to the
+container it will report the version you are currently using.
+
c7 will not pick up new releases of the
+container image unless you explicitly ask it to pull the latest again:
+
c7-dp
+
+
+
If you would like to roll back to a previous version
+of the container then use the -v option:
+
c7-dv2.2.0
+
+
+
To check what versions of the image are available, take a look at the
+github container registry for this project
+https://ghcr.io/dls-controls/dev-c7
Note that the container should be considered ephemeral. The system partition
+can be changed and you have full sudo rights, but note:
+
+
Changes inside the container such as yuminstall will be persisted,
+but only until it is deleted.
+
Deletion is under your control, see below. However you will always need
+to do a delete before updating to a new version. Therefore it is a bad
+idea to accumulate many changes inside of the container.
To reset the container back to its original state we ask podman
+to stop it and delete it.
+
+
Warning
+
Everything running in your container will be terminated when you
+do this. Make sure you have saved your work and closed all
+applications.
+
+
The following will stop the container and delete it’s state. All
+dev-c7 shells and any GUI apps launched from them will be closed:
+
podmanrm-ft0dev-c7
+
+
+
When you next launch the container, it will be started with its file system
+initialized back to the default state specified in the image at
+ghcr.io/dls-controls/dev-c7:latest.
+
You can also ask c7 to perform the delete for you with -d.
+
+
Warning
+
Any changes you have made to the container itself will be lost when you
+execute the above command. This includes
+any yuminstall and any changes to the operating system files.
+See How the dev-c7 Container Works for more detail. To permanently
+persist changes see Derive your own container image.
It is useful to have a way to tell you are inside of the developer
+container. By default your bash prompt will look exactly the
+same inside and out of the container.
Typically the PS1 prompt shows you which host you are on. You can change
+the name of the host inside the container to give you an indicator that
+you are in the developer container.
+
When using the launch script for initial creation of the container you
+can pass a hostname of your choice as follows.
+
c7-smy-hostname
+
+
+
+
Warning
+
If you are working remotely and launching the container from an
+ssh session changing the hostname will cause X11 apps to fail.
if don’t have a $HOME/bin folder then you will need to do
+mkdir$HOME/bin. It will automatically be added to your PATH in
+any new shells, but the current shell won’t see it.
+
+
+
Note
+
For the first invocation of an updated version of the container there
+will be a 30 second delay while the filesystem user id namespace mapping
+is cached. This will happen after the image is pulled from the registry.
At a dev-c7 prompt you can work normally as if you were sitting at a RHEL7
+workstation. Everything should work as before although there are a few
+differences, see
+RHEL7 native vs dev-c7.
+
If you find anything that does not work or have suggestions for improvement,
+please report it
+On GitHub Issues.
+
+
You can launch multiple instances of dev-c7 and they will share the
+same container.
+
You can run gnome-terminal and open multiple tabs - all will be in the
+container
+
You can use module load as usual to make further software from dls_sw
+available
+
You can run GUI apps as normal.
+
You have full sudo rights and can install anything you need into the
+container with yuminstall
+
Do NOT run vscode inside the container. Instead run it normally and
+feel free to launch dev-c7 inside of its integrated terminals to do
+compilation, testing.
If you are using edm and the fonts look wrong or you get errors about
+missing fonts, then read on. This should not be required for RHEL8 machines
+at DLS which should already have the fonts installed.
+
The edm display manager uses local fonts that need to be installed on your host.
+
Again, these should be part of the standard RHEL8 installation but early
+adopters may need to install them as follows:
Add the following settings to you user configuration for VSCode in
+$HOME/.config/Code/User/settings.json
+
These settings ensures that each terminal loads the bash (login) profile by
+default.
+Bash will then run .bash_profile and this includes essential setup for
+DLS controls developer environment.
To use VSCode with a developer container, first add the
+.devcontainer folder with devcontainer.json
+file to the root of your project. The script has a helper to do this:
You can recreate the container from scratch by deleting it with podmanrm
+or you can tell VSCode to rebuild it using the remotes menu. This menu is
+accessed by clicking the icon in the very bottom left of the VSCode window.
The remotes menu option RebuildContainer will close the session,
+rebuild the container
+and reopen the session in the new container.
+
Note that this means that the containers used by VSCode and those used
+by c7 are distinct. So if you install something into one it will
+not be seen in the other.
+
+
Note
+
VSCode will use a different container for each folder. If you would
+like to share a container between folders:
+
+
open multiple folders in a single VSCode session by choosing “Add
+Folder to Workspace” from the right click menu in the File Explorer
+
choose File->SaveWorkspaceAs... and save the workspace to a
+file, usually in the folder that is a common root to your projects.
+
copy the .devcontainer folder to the same folder as the workspace
+file.
+
go to the remotes menu (icon in bottom left of VSCode) and choose
+ReopenContainer
When a devcontainer is launched, it will usually start a single terminal that is
+NOT using the login profile. This means you won’t see your usual bash prompt
+and none of the DLS development environment will be available.
+
To work around this, close and reopen the 1st terminal
+or type:
+
bash-l
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Other Versions
+ 2024.8.1gui
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/versions.txt b/versions.txt
index f1426f2..e0726ef 100644
--- a/versions.txt
+++ b/versions.txt
@@ -1,4 +1,5 @@
main
+2024.8.1gui
2024.8.1
2.3.3
2.3.2
+