DESK On Linux Project
From DDCIDeos
Jump to navigationJump to search
A project to get the DDS working on Linux. See also DESK_On_Docker_Project.
Description
A similar, but unfunded, project exists for Mac OS X.
Status
At this point it is possible to install many variations that all have similar capabilities as Cygwin including using OpenArbor:
- Use run-docker on Linux. See also DESK_On_Docker_Project.
- Install a WSLg DDS container
- Install a WSLg Linux distribution and use run-docker from within that.
Run docker on windows– possible, but not recommended.
How to use
Known issues
- When running in a VM that has windows file system mounted and is used by a docker container:
- Symbolic links don't work
- scripts can only be run once at a time (while the script is active the "x" bit is cleared).
- Running OpenArbor generates this diagnostic:
- AppArmor policy prevents this sender from sending this message to this recipient
- qemu network applications that depend on accessing external networks do not work.
Tasks
See also the dependency tree for PCR 11426.
| ID | PCR | Item | Priority | Assignee | Phase | Category | Comments |
|---|---|---|---|---|---|---|---|
| 2 | TBD | Investigate options for package management like scheme(s) (e.g., APT proxy, RPM, docker registry, git repo, etc.) | 99 | AL | Dev | BuildInfra | |
| 3a | PCR:13418 | update 653 CVT to not use py2exe | 2 | CF | Done | DeosComponent | |
| 3b | PCR:13419 | update registry CVT to not use py2exe | 2 | CF | Done | DeosComponent | |
| 3c | PCR:13420 | update ioi CVT to not use py2exe | 2 | TBD | Done | DeosComponent | New kfs-cvt also doesn't use py2exe. |
| 6 | TBD | Improve Debian installer | 99 | TBD | Pending | DeosComponent | Current installer works about like Cygwin. It would be better if it tracked inter-component version dependencies as is possible with .debs. |
| 11 | PCR:13083 | TDL install on Linux is broken | 2 | Matt.V | Pending | DeosComponent | |
| 13 | TBD | docker .tar.bz2 was corrupted. | 1 | BC | Done | DeosComponent | Customers no longer having difficulty. |
| 15 | TBD | Qemu all white display problem on native CentOS linux install | 99 | TBD | Pending | DeosComponent | |
| 16 | TBD | Cannot build OA docs on Linux | 99 | LCJ | Pending | OpenArbor | Workaround: build on Windows |
| 17 | DDCI_PCR:4148 | Served license support | 15 | LCJ | Done | OpenArbor | The license server (lmgrd and supporting tools) can be built on Linux. Testing is complete. The packaging of the Linux licensing files for distributions to a customer also needs to be done. |
| 18 | TBD | License borrowing | 15 | LCJ | Done | OpenArbor | This has been tested on Linux with a served license. |
| 20 | DDCI_PCR:4146 | inconsistencies between Windows vs Linux behaviors (e.g., double-click) | 99 | LCJ | Pending | OpenArbor | |
| 21 | TBD | OA Icons / shortcuts | 3 | LCJ | Pending | OpenArbor | |
| 22 | DDCI_PCR:4175 | add DDS - list available docker images to test | 1 | NH | Done | TestInfra | |
| 23 | DDCI_PCR:4175 | install - setupDDCI for linux (sudo apt-get upgrade and install?) | 1 | NH | Done | TestInfra | |
| 24 | DDCI_PCR:4175 | runUninstaller | 99 | NH | Done | TestInfra | |
| 25 | DDCI_PCR:4175 | setup | 99 | NH | Done | TestInfra | |
| 26 | DDCI_PCR:4148 | startLicenseDaemon | 1 | NH | Done | TestInfra | |
| 28 | TBD | Decide on 12500 vs 10000 System Tick Rate | 1 | BC | Done | WorkStep | Moved to a different project |
| 29 | TBD | Debug sessions require manual suspend for some apps | 3 | TBD | Dev | DeosComponent | Unable to reproduce for multi-threaded-process. For buffer_semaphore, gdb appears to be setting a breakpoint in code subsequently executed in kernel mode. Retested with DDS-docker-deserteagle-cffs-deos-kisment-20220426. Media:buffer-semaphore-config-linux-debug.png |
| 30 | TBD | Determine why debugging udp-vs-tcp not working at all | 3 | LCJ | Done | WorkStep | udp-echo.py script reports an error. Tested with DDS-docker-deserteagle-cffs-deos-kisment-20220426. Media:upd-vs-tcp-linux-manual-test-pass.png |
| 33 | TBD | Have /OpenArbor on the path, or put a link to OpenArbor executable from /desk/bin | 5 | AL | Pending | DockerImage | |
| 36b | TBD | Maintainer Working with unreleased/test components | 3 | AL | In Work | BuildInfra | There is a command line script, no GUI yet. |
| 37 | TBD | RTEMS | 1 | AL/RLF | Done | DeosComponent | |
| 39 | DDCI_PCR:4151 | Fix failing open arbor tests on linux | 1 | LCJ/NH | Done | Workstep | OpenArbor_10.1.0_Test_Plan_and_Report_Celestial_D2#Testing_Notes |
| 40 | Only one tap device works at a time | 99 | TBD | Pending | Although docker containers create multiple tap devices, the routing is configured such that only one works at a time. | ||
| 41 | Enable component testing on Linux | 5 | TBD | Done | Works for kernel, ansi, gnu-language and others. | ||
| 42 | Subversion config file install | 99 | TBD | Pending | Given the number of permutations of potential maintainer environments, its hard to know how to proceed. | ||
| 43 | Enable mmio support on qemu | 20 | TBD | Pending | MMIO support was disabled during preliminary qemu port, it must be re-enabled. | ||
| 44 | Linux gcc packages do not have a postinst script to run makelib.py. | 99 | TBD | Rejected | No need for this since Linux will not generate PE executables. | ||
| 45 | Add OA shortcut to create shell | 5 | LCJ | Done | Ensures that the shell shares the OpenArbor container. | ||
| 46 | DDCI_PCR:494 | Add OA icon to start DESK shell | 3 | LCJ | Done | OpenArbor | OA to launch a command line shell in the environment of OpenArbor with a working directory set to someplace within the workspace, perhaps at the root, perhaps something more specific. Ideally an Icon on one of the window tool bars or something like that. On windows this could be done using mintty or even the CMD shell, but running bash. On Linux we'd have to add gnome-terminal (only about 2MB more on the install), and it could be started with gnome-terminal. Or define a desk-terminal command that OA could invoke that would do the above as appropriate. User could then create their own desk-terminal command to customize. |
| 47 | Fix firefox for 2022 distros | 3 | Pending | DeosComponent | In 2022, firefox doesn't work (it wants to be installed as a snap). |
''Legend''
ID: Just a number to be able to quickly refer to an item during a meeting, etc.
PCR: Link to the PCR is one has been written or TBD if there is no PCR
Item: Short description of task to be worked
Priority: A number 1 - 99
- 1 required for going "non-beta".
- 2 required by jupiter verf (release date est 8/31/2022).
Assignee: The person responsible for doing the work associated with the component.
Phases:
- Blank - Not yet started
- Dev - In Development
- Test - Component unreleased and ready to test
- Delta - A Delta baseline must be established
- Audit - One (or more) SQA Audits must be performed (e.g., a Verification and/or Software Conformity Audit)
- Stable - You are done! All steps (including test report) in the Deos Software Release HowTo or OpenArbor Development HowTo have been followed.
Category: One of the following: BuildInfra || DockerImage || DeosComponent || OpenArbor || TestInfra || WorkStep || TBD
Comments: Free form text.
Strategic Planning
On Windows the main issue is the deployment strategy, and secondarily image vs container.
The options:
- docker in WSLg
- side load DDCI DDS as a WSLg distribution
On Linux the main issue is image vs container.
The options involving additional layers of virtual machines are possible, but seem increasingly less probably desirable with each layer inserted.
Image or Container
Should the user see a docker Image or a Container? ('+'=='Pro', '-'=='Con')
- File System Issues:
- On Linux file system access is equally fast and semantically equivalent for host vs docker file systems.
- On Windows host file (e.g., NTFS) access is slow and guest symbolic links don't work
- This means that there will be pressure to use the file system inside the container on windows.
- Windows WSL is optimized for using a container (not image)
- Upgrades
- A container has user state and the contents of a distribution installed at a global location, e.g., /desk. When DDCI delivers a new DDS, how does the user upgrade?
- Installed tools, e.g., editors, wireshark, etc.
- It would not be possible to add tools to a DDS based container – DDCI does not make the repository publicly available, and if a user were to install tools from the internet they would most likely render the container unusable due to version skew between DDS tools and net versions.
- On WSLg it is possible to run windows executables from within the WSLg container, but (maybe?) not from a docker container within the WSLg distribution.
- Networking
- There is complexity going between a WSLg or docker container and the host network.
- Container initiated connections seem to work well.
- WSLg has issues with name resolution (Microsoft bug).
- containers (both Linux/Docker and WSLg) have special configurations for host to/from container networks.
- There is complexity going between a WSLg or docker container and the host network.
File visibility
Host residient tools can't easily see into a dynamically created container's file system. A "static" container could be mounted on the host (at least for linux): Ref https://stackoverflow.com/questions/20813486/exploring-docker-containers-file-system#answer-55253209
PID=$(docker inspect -f 'Template:.State.Pid' your-container-name-here) cd /proc/$PID/root
WSL has a way to deal with this (e.g., file explorer penguin) Host programs (e..g, PE .exe files) have access to docker container files.
An image has a fixed CRC, so we could tell whether the image was corrupt.
- It is possible to verify the contents of a container match the original md5sums, however that is not robust (many failures):
- sudo dpkg --verify | grep -v /usr/share/man | grep -v /usr/share/doc | grep -v /usr/share/locale
Pros/Cons: Both:
- - (windows) must have a GUI/X server installed (fixed with WSLg).
Image
- + Easy to ensure the image is unchanged from what was delivered by DDCI
- - (windows) Referencing host file systems is slow
- - Referencing image specific files from the host is difficult, e.g., /desk/help
- -- Note especially editors and other "make" invoked tools.
Container
- - Many of the problems of having a second PC, managing redundant tool configurations, etc
- - Administrative activities hard to apply to container files, e.g., backups
- - Must choose a name for the container and a path to access files from host
- -- Protocol for having more than one container based on an image, note this is especially concerning for Linux since mount points are typically host, not user based.
Windows WSl{1,2,g} has chosen the container approach and have a means for host based tools to access the container using a host style mount point, e.g., \\wslfoo\container\pathname
On Windows it seems like WSLg is the likely best strategy, but then the question is does DDCI deliver a WSL distribution, or use a docker container started from within the WSL distribution?
docker from within WSL
- + One home directory and can share scm checkouts
- + Much easier to upgrade to a new distribution (or have multiple).
- - Haven't been able to get GUI to work that way (yet).
WSL distro
- - Have to create a side loaded distribution, which requires custom installer technology.
- - Prototype support is in build-docker.
Docker on Windows (not seriously considered)
- - DDCI would have to solve (all) the problems Microsoft resolved via WSLg, e.g., graphics and file system issues.
Strategy for Creating Images
This section is mostly obsolete. The functionality described is implemented in the current subversion HEAD of wsl and docker
If we want to use the same docker .tar.gz file for both WSL and docker, we need to change the docker install command. "docker image load" does not work with .tar files created via "docker image export" so we must change the install command from:
docker image load -i dds-docker-celestial-jupiter-20210216.tar.gz
To import an exported image:
docker image import -c "CMD /bin/bash -i" dds-docker-celestial-jupiter-20210216.tar.gz dds-docker-celestial-jupiter-20210216
Could simplify run-docker and make wsl and docker more similar by making wsl/branches/mainline/ddci-dds.sh be the means of changing the path. This would require that the default /etc/profile be run by all shell startup scripts. This may be a problem for sophisticated customers since they probably have their own profile and .bashrc files, and run-docker shares a home dir with the host.
- We could stop sharing home dir. - Tell users they must run /etc/profile
This would also simplify getting command completion for DESK commands.
WSl puts the license file info into /etc/profile.d/ddci-dds-license.sh
- Currently there is no tool to change the license, but since this is a container the user could edit the license.sh file directly.
docker puts the license info on the run-docker generated command line.
- That probably makes managing multiple user installs more difficult for the customers because each user must specify the environment variable.
Notes for starting a persistent container
- Create a persistent container (note removal of --rm, and add of --detach)
- This also sets the default working directory for all future exec cmds.
- May also want --restart=unless-stopped
run-docker -it --detach --name=customer-foo ubuntu-jupiter-dev
- Connect to the container. You can do this as many times as desired.
docker exec -it customer-foo bash -il
or
docker exec -it customer-foo /OpenArbor/OpenArbor
- Delete the container
docker container stop customer-foo # probably would be good to stop before a host shutdown docker container rm customer-foo
- Browse the container file system:
xdg-open /proc/$(docker inspect -f 'Template:.State.Pid' customer-foo)/root/
- Aaron has a prototype script to dump processes, see ~alarson/bin/docker-processes
WSL2
On windows, it probably makes more sense to use WSL2 rather than docker. Microsoft has made subsystems integrate well with the Windows file system, and has native GUI support on Windows 10 and Windows 11 (an integrated Windows Wayland server).
WSLg allows the user to run Linux GUI application on their Windows host. The host must be a recently up to date Windows 10 or 11 machine, see https://github.com/microsoft/wslg for specific pre-requisites.
- Installation
The following are historical notes, issues, and observerations. They are not required to use the DDCI WSLg installation.
- Versioning
- software packages are bound by the version of the Ubuntu mirrored for the container image
- tools may not be up to date which can cause issues
- depending on the Linux flavor and version, certain programs may no longer be supported, e.g., Ubuntu 2020 supports both Firefox and Google Chrome while Ubuntu 2022 supports only Google Chrome
- package manager like apt must be used to control versions
- don't have a good way to move forward and backward between Deos component versions yet
- maybe a script like https://deos.ddci.com/scm/Deos/maintainer-tools/docker/branches/mainline/unrelease to update versions
- software packages are bound by the version of the Ubuntu mirrored for the container image
- Graphics
- bugs are distribution-wide, but infrequent
- this means if any graphics program fails, they all fail on that distribution and require a full WSL reboot
- requires some extra steps to get the minimize and maximize buttons to show up
- some issues with right-click window sizing, double-clicking, and mouse flickering in OpenArbor
- lose any Windows host abilities to organize open content on the screen
- bugs are distribution-wide, but infrequent
- Linking
- Windows Explorer has a separate section dedicated to WSL to give the host access to the entire WSL filesystem
- can have multiple WSL distributions but cannot share files between them
- host tools can modify WSL files and vice versa for the most part
- it is recommended that all work done on the WSL filesystem remain in the WSL file system
- best practice is to keep host and container work separate
Podman
Docker runs with privileges, podman runs as the user.
- podman is likely going to be better accepted by our customers given its security advantages.
- Haven't been able to get qemu to work (insufficient network privileges).
Get UID correct: https://stackoverflow.com/questions/70770437/mapping-of-user-ids
cat /etc/subuid alarson:100000:65536 mainline$ id uid=1000(alarson) gid=1000(alarson) groups=1000(alarson),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),120(lpadmin),131(lxd),132(sambashare),133(docker)
uid=1000 subuidStart=100000 subuidSize=65536
run-docker -it --rm --uidmap $uid:0:1 --uidmap 0:1:$uid --uidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) --gidmap $uid:0:1 --gidmap 0:1:$uid --gidmap $(($uid+1)):$(($uid+1)):$(($subuidSize-$uid)) ubuntu-jupiter-dev https://stackoverflow.com/questions/70770437/mapping-of-user-ids
Docker
- Customer installation
- Where does display/x-server get installed on Windows? (should be able to assume X is always installed on Linux)
- install docker
- docker image load from file, or DDCI server?
- docker security
- perhaps rootless: https://docs.docker.com/engine/security/rootless/
- current image might work with passwordless sudo.
- Discuss/consider: security implications of deploying docker on
- DDCI workstations
- Customer installations
- Debian packages/deos2cygwin issues
- Do we need signed repository for authentication (integrity is ensured via SHA)?
- How to handle QA issues:
- Some packages have Linux specific content (a separate "zip" file for linux). Should that be versioned separately from the Cygwin package?
- None of the existing packages have test reports for Linux, how should that be handled?
- Some packages have no linux specific content, some have separate .zip files, some have linux specific logic. Are these separate cases for QA?
Other issues
Detailed list of items to do
The following is a summary of the issues. A detailed deos2cygwin.py log file from a complete build of the ubuntu-ddci repository can be found at:
Media:Deos2cygwin-2020-12-22.log.txt
Package specific issues
- ddci-desk has desk_menu_path which is used for creating distribution specific desktop links. No idea what to do with that.
- gcc-ppc64-elf/package2cygwin.py uses "linux" for the name containing the windows compilers.
- gdb-8.0.1.2-linux-x86-64-cross-debuggers doesn't have a test report, however the windows variant does. Will be the same for other packages containing Linux content.
- The kernel's use of gcc-x86-pe-addons implicitly depended on the fact that the host workstation was running windows in order to get the GCC PE compiler. That is no longer true.
- suggest not porting kernel PE tests, wait for kernel 64-bit to obsolete PE.
DOSisms
- The following files/components reference cygpath (only potentially inappropriate items listed):
/desk/bin/desk_menu_path test-abcscat test-deos653cvt test-ioi-cvt test-registry-cvt ToMixed.pm abc examples platform/minnow-turbot-quad
These bogus postinstall scripts exist in current packages on the ftpserver:
-rwxr-xr-x 1 root root 557 May 7 2019 deos-subversion.sh
Postinstall Scripts
The following are postinstall scripts that do something: ./afdx-driver-config/postinstall/afdxconfig-postinstall.sh Can be used as is for Linux ./afdx-examples/postinstall/afdx-examples.sh Can be used as is for Linux ./deosbook/postinstall/deosbook.sh Updated for Linux ./deosbook-devel/postinstall/deosbook-devel.sh Updated for Linux ./deos-subversion/postinstall/deos-subversion.sh ISSUE: Distributing maintainer subversion config file needs to be worked out. ./deos-maintainer-tools/postinstall/deos-maintainer-tools.sh shortcuts ./desk/postinstall/desk.sh shortcuts and removal of "confusing files" ./gcc-desk/postinstall/gcc-desk.sh shortcuts ./graphviz/postinstall/graphviz.sh Package obsoleted for Linux. ./heartos-desk/postinstall/heartos-desk.sh shortcuts ./heartos-maintainer-tools/postinstall/heartos-maintainer-tools.sh shortcuts ./pyPdf/postinstall/pyPdf.sh Updated for Linux OBSOLETE ./msvcr80/postinstall/msvcr80.sh ./msvcr90/postinstall/msvcr90.sh ./score-other-docs/postinstall/run_configure_score_other_docs.sh ./unused/integ-tool-classic/postinstall/integ-tool-classic.sh ./unused/status-monitor-mfc-gui/postinstall/status-monitor-mfc-gui.sh ./VMware-player/postinstall/VMware-player.sh Following pacakge have standard library building post install scripts. Most of these probably are not needed anymore since I think they are only used by Honeywell. ./a653p1-runtime/postinstall/run_update_deos_libs.sh ./a653p4-runtime/postinstall/run_update_deos_libs.sh ./afdx-library/postinstall/run_update_deos_libs.sh ./apm-cale-prl/postinstall/run_update_deos_libs.sh ./arinc664-library/postinstall/run_update_deos_libs.sh ./cffs-server/postinstall/run_update_deos_libs.sh ./deos653p4-runtime/postinstall/run_update_deos_libs.sh ./gcc-aarch64-elf/postinstall/run_update_deos_libs.sh ./gcc-arm-eabi/postinstall/run_update_deos_libs.sh ./gcc-mips-elf/postinstall/run_update_deos_libs.sh ./gcc-ppc-elf/postinstall/run_update_deos_libs.sh ./gcc-ppc-elfspe/postinstall/run_update_deos_libs.sh ./gcc-ppc64-elf/postinstall/run_update_deos_libs.sh ./gcc-x86-elf/postinstall/run_update_deos_libs.sh ./gcc-x86_64-elf/postinstall/run_update_deos_libs.sh ./imageapi/postinstall/run_update_deos_libs.sh ./internet-api-library/postinstall/run_update_deos_libs.sh ./ioi-api/postinstall/run_update_deos_libs.sh ./ioi-pipcBuffer/postinstall/run_update_deos_libs.sh ./ioi-ringBuffer/postinstall/run_update_deos_libs.sh ./mailbox-transport-library-mips/postinstall/run_update_deos_libs.sh ./math-ppc/postinstall/run_update_deos_libs.sh ./math-x86/postinstall/run_update_deos_libs.sh ./produce/postinstall/run_update_deos_libs.sh ./rtl81xx-prl/postinstall/run_update_deos_libs.sh ./socket-api-library-mips/postinstall/run_update_deos_libs.sh ./tsec-durant-prl/postinstall/run_update_deos_libs.sh
