From inside of a development container for VSCode (Debian Linux) I'd like to use a COM port for communication via an USB device connnected to the Windows host machine (via WSL2). How can I make the COM port available insie of the container?
EDIT:
For WSL2 there is no official support yet.
As of right now WSL 2 does not include serial support, or USB device support.
A corresponding feature request is tracked on GitHub.
July 2021: As of right now WSL 2 does not include serial support, or USB device support.
Update November 2021: the same FAQ states:
Skanda Hazarika reports:
You can now connect USB devices in Windows Subsystem for Linux under Windows 11
If you’re an active user of Windows Subsystem for Linux and want to access USB devices right from the Linux instance running under WSL, then you’ll be happy to know that there has been a significant progress in this front.
Thanks to Microsoft’s contributions to the open-source dorssel/usbipd-win project, you can now enjoy USB passthrough access in WSL.
It means end users can perform tasks like flashing Android devices under Windows Subsystem for Linux, which are otherwise not supported by the Linux subsystem.
The usbipd-win project is all about creating a solution for sharing locally connected USB devices to other machines, including Hyper-V guests and WSL2. However, the official WSL2 Linux kernel used to lack support for the USB/IP protocol, requiring users to build the kernel themselves.
Since WSL kernel version 5.10.60.1, the required parameters are configured out of the box, so no manual recompilation is needed.
Microsoft has also contributed a command line interface to the project to both enable a USB device for sharing on Windows and seamlessly attach it from within WSL.
So if you have:
migrated/upgraded to Windows 11
applied all WSL updates (through the Windows Store)
Then, your VSCode should be able to access mounted USB drives through WSL.
How to install the jenkins on a solaris server? i found articles that this cannot be done as jenkins has discontinued support for solaris.
Even though official IPS repositories for Solaris are discontinued, you can still run Jenkins in Solaris via the jenkins webapp (jenkins.war). To quote from Jenkins installation doc:
Solaris, OmniOS, SmartOS, and other siblings
Generally it should
suffice to install Java 8 and download the jenkins.war and run it as a
standalone process or under an application server such as Apache
Tomcat.
Some caveats apply:
Headless JVM and fonts: For OpenJDK builds on minimalized-footprint
systems, there may be issues running the headless JVM, because Jenkins
needs some fonts to render certain pages.
ZFS-related JVM crashes: When Jenkins runs on a system detected as a
SunOS, it tries to load integration for advanced ZFS features using
the bundled libzfs.jar which maps calls from Java to native libzfs.so
routines provided by the host OS. Unfortunately, that library was made
for binary utilities built and bundled by the OS along with it at the
same time, and was never intended as a stable interface exposed to
consumers. As the forks of Solaris legacy, including ZFS and later the
OpenZFS initiative evolved, many different binary function signatures
were provided by different host operating systems - and when Jenkins
libzfs.jar invoked the wrong signature, the whole JVM process crashed.
A solution was proposed and integrated in jenkins.war since weekly
release 2.55 (and not yet in any LTS to date) which enables the
administrator to configure which function signatures should be used
for each function known to have different variants, apply it to their
application server initialization options and then run and update the
generic jenkins.war without further workarounds. See the libzfs4j Git
repository for more details, including a script to try and "lock-pick"
the configuration needed for your particular distribution (in
particular if your kernel updates bring a new incompatible libzfs.so).
Also note that forks of the OpenZFS initiative may provide ZFS on
various BSD, Linux, and macOS distributions. Once Jenkins supports
detecting ZFS capabilities, rather than relying on the SunOS check,
the above caveats for ZFS integration with Jenkins should be
considered.
Docker installation guides does contain three different ways of installing Docker. I want to know the exact difference between the three components.
Docker CE (Community Edition) is the simple classical OSS (Open Source Software) Docker Engine.
Docker EE (Enterprise Edition) is Docker CE with certification on some systems and support by Docker Inc.
Docker CS (Commercially Supported) is kind of the old bundle version of Docker EE for versions <= 1.13.
Take a look at this blog post and this other one about Docker CE & Docker EE.
"What is Docker Enterprise Edition?
Docker Enterprise Edition comes in three versions: basic, standard and advanced. The Basic edition comes with the Docker platform, support and certification, while the Standard and Advanced version add additional features such as container management (Docker Datacenter) and Docker Security Scanning.
Docker EE is supported by Alibaba, Canonical, HPE, IBM, Microsoft and by a network of regional partners. Those who want to test Docker EE can download a trial version for free from the official site.
Docker is also offering a certification program to help third-party vendors in ensuring their products work with Docker EE.
What is Docker Community Edition?
Docker Engine has been renamed to Docker Community Edition, and, as the name suggests, it’s a do-it-yourself, community supported version of Docker that’s available for free of cost.
The community edition will be available in two versions: Edge and Stable. Edge will be released each month with the latest features. Stable will be released on a quarterly basis. While Edge will receive security updates and bug fixes for the current release, the stable version will get similar updates for four months after the initial release. This update cycle will give users a big enough window to plan upgrades from older versions.
While the two versions are targeted at different audiences, there isn’t much, or any, difference at source code level. “Both Docker EE and CE are based on the open source Docker project, which is developed in the open with Docker’s community of partners and contributors, and this forms the open, modular core of all Docker CE and EE editions,” said Messina."
From CIO.com
Also, take a look at the resources here and the official Docker documentation.
TL;TR;
We are currently dealing with two editions of Docker: Docker Community Edition (CE) and Docker Enterprise Edition (EE).
Docker EE comes with additional features that can help enterprises launch, manage, and secure their containers more efficiently, but what is worth emphasizing is that the two editions offer the same core features.
The main differences are that Docker CE is a free to use for everybady and open source and, on the other hand, Docker EE in the basic plan costs $1,500 per node, per year...
Another important difference is the operating systems on which we can run them. Docker CE can run on Windows 10 and Mac, on Azure and AWS, as well as CentOS, Debian, Fedora, and Ubuntu and Docker EE can run on Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), Oracle Linux, Ubuntu, Windows Server 2016, as well as Azure and AWS.
Thus, in most private and commercial cases of Docker use, Docker CE should be sufficient.
For an in-depth look at all the differences, I encourage you to visit:Docker Community Edition or Docker Enterprise Edition - Everything You Need to Know
Docker CE vs EE: An Overview
Docker CE is a free and open source containerization platform. It is a rebranded version of the Docker open source solution that has been freely available since the launch of Docker in 2013.
CE can run on Windows 10 and Mac, on Azure and AWS, as well as CentOS, Debian, Fedora, and Ubuntu. CE can be downloaded directly from the Docker Store.
Docker EE, on the other hand, is a premium version of CE. Docker EE is an integrated, fully supported, and certified container platform that runs on Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), Oracle Linux, Ubuntu, Windows Server 2016, as well as Azure and AWS.
Docker CE vs EE: How They’re the Same
First things first, it’s important to note that Docker CE is not a ‘watered down’ version of Docker EE. Both CE and EE have the same core features and functions:
Both editions are updated quarterly (although Docker CE users can expect “Edge” updates, discussed further herein), and both are available on a wide range of popular operating systems and cloud infrastructures, giving enterprises the freedom to run containerized applications on their favorite infrastructure—without lock-in.
Docker CE vs EE: How They’re Different
While both editions offer the same core features, Docker EE comes with additional features that can help enterprises launch, manage, and secure their containers more efficiently.
Here’s a summary of what companies can do when using Docker Enterprise Edition:
Gain access to certified Docker images and plugins
View your container clusters in a single pane view
Access controls for cluster and image management
Receive official same-day support from Docker
Run vulnerability scans on your Docker images
Run Docker EE engine with FIPS 140-2 certification
Advanced image and container management, LDAP/AD user integration, and role-based access control (formerly available only through Docker Datacenter, which is now part of the Docker EE plan)
Continuous vulnerability monitoring and Docker Security Scanning (formerly available only through Docker Datacenter, which is now part of the Docker EE plan)
Understanding Docker’s Versioning Format
As you research Docker CE and Docker EE, you may wonder about the platform’s versioning format. On the release of both CE and EE, Docker decided to change the way they versioned their product. Before March 2017, the latest version of Docker that was available at the time was v1.13. After the rollout of CE and EE, the new version was referred to as 17.03.
From the outside, it seemed as if Docker had skipped past 16 versions, but in actuality, Docker had changed their versioning scheme to YY.MM (year and month), similar to the scheme used by Canonical for Ubuntu..
How Often Are Docker CE and Docker EE Updated?
Docker CE comes with two release channels: “edge” and “stable”.
The edge channel releases a new version every month, and you gain the advantage of getting new features with each release. As for the stable channel, a new release becomes available every quarter.
If you decide to go for the stable option, you will have to wait longer to get the new features; however, on the plus side, the stable channel is much easier to maintain since you only need to install an update every quarter, as previously mentioned. The edge channel is suitable for those who want access to the latest features quicker.
In terms of support for both channels, the edge channel only releases bug fixes and security patches during the version’s current month. The stable channel releases patches for security issues and bug fixes for 4 months after the initial release, giving users a one-month window to upgrade to the latest release while still receiving fixes.
With Docker EE, a new version is released every quarter, and each release is supported for a full calendar year. Both bug fixes and security patches are backported to all supported versions.
Source: Docker
Docker CE vs EE: Pricing
Docker CE is free to use and download. The overall experience of CE can be enhanced through a range of free and paid add-ons from Docker Cloud at your own discretion.
Docker EE is a premium version that is available through three pricing tiers:
Basic: With Basic Docker EE, you get the Docker platform for certified infrastructure, along with support from Docker Inc. You also gain access to certified Docker Containers and Docker Plugins from Docker Store.
Standard: Comes with the same features as the Basic tier but with added advanced image and container management (single pane view), LDAP/AD user integration, and role-based access control (Docker Datacenter).
Advanced: Comes with added Docker Security Scanning and continuous vulnerability monitoring.
The general pricing for each tier is usually based on cost per node per year:
Basic: $1,500 per node, per year with Business Critical support
Standard: $3,000 per node, per year for Business Critical support
Advanced: $3,500 per node, per year for Business Critical support
Docker EE is also available as a one-month free trial. To activate your Docker EE free trial subscription, log into The Docker Store and navigate to the Docker EE page.
I've recently been trying to set up a Jenkins server that uses the Jenkins MKS plugin for version control. I had a Windows Jenkins server that was running this same configuration just fine, and now that we're moving it to a linux server (Red Hat Enterprise Linux Client release 5.1 Tikanga), it doesn't seem to be able to download the files. The folder structure is built perfectly fine, which tells me connecting to the server isn't the problem, but the files aren't populated in the folders.
Jenkins System Log:
Sep 02, 2016 11:15:46 AM WARNING org.apache.commons.httpclient.HttpMethodBase readResponseBody
Unsupported transfer encoding:
Sep 02, 2016 11:15:46 AM INFO org.apache.commons.httpclient.HttpMethodBase readResponseBody Response
content is not chunk-encoded
Sep 02, 2016 11:15:46 AM INFO hudson.model.Run execute
Test #67 main build action completed: FAILURE
Any suggestions on what I can do to check if my data/files are chunk encoded, or why this would be unique to a linux server? I realize we’re 3+ years behind on our configuration, but IT here has tight restrictions on what software can be installed and updated. Any troubleshotting suggestions or help is much appreciated!
Config Details:
Jenkins Version 1.596.3
MKS Plugin Version 1.16 MKS Server: MKS Integrity Client 2009, Build
4.10.0.9665, SP 007-01
Jenkins Slave info: Red Hat Enterprise Linux Client release 5.1
(Tikanga)
Java version 1.7.0 Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Server_VM (build 21.0-b17, mixed mode)
Similar issues / Research:
This issue report perfectly describes my problem, but the comment section suggests that the Java 7u40 update causes the issue, whereas I'm on an earlier version of Java.
https://issues.jenkins-ci.org/browse/JENKINS-21638
This issue describes the log error I'm seeing, but comment section suggests it was solved by Jenkins version 1.577. We're using a newer version of Jenkins. https://issues.jenkins-ci.org/browse/JENKINS-16985
You're using Integrity 10.9: As per the Version 2.0 (Jan 27, 2016) entry on the Plug-in's page:
IMPORTANT – PTC Integrity Plugin 2.0 is not backward compatible.
Please create new Jobs.
Productized version of PTC Integrity Plugin
compatible with PTC Integrity 10.9. Versions older than Integrity
10.9 are no longer supported.
I think what Cletus is trying to explain in that post is that both the version of Java used to build the plug-in and the version of Java running Integrity should be the same, and in the case linked for JENKINS-21638, changes in the 'File' object after Java 7u40 are preventing the plug-in from fetching files from the server.
If you were on a version of Java earlier than 7u40 (e.g. 7u25) it should work. Integrity 2009 SP6 (and hence the mksapi.jar file) were compiled with Java 6, so it's likely you're running into a similar issue there. Having said that, I'm working on an educated guess here, so you'd actually need to test that to see if it works.
I need to use Docker / Windows containers on Windows 2016 Server and prepare it Windows applications to run on it.
Configuring Windows via Powershell just is not as convenient though as it is on Ubuntu, especially if you never worked with Windows Server really and need to learn all the Powershell commands ;)
Is there a way to access a Windows Container via GUI?
It's possible with Docker, Ubuntu, VNC:
Can you run GUI apps in a docker container?
Wondering if anything similar can be done for Windows Containers?
(I am working on-premise, not using Azure. Found a similar but unanswered question here: https://stackoverflow.com/questions/32721422/windows-server-containers-azure-how-to-create-a-container-with-gui)
Thanks.
== Update ==
RDP is definitely not an option as per February 2016 - not sure if they plan to support it in the final release?!
https://msdn.microsoft.com/en-us/virtualization/windowscontainers/about/work_in_progress#remote-desktop
Remote Desktop
Windows Containers cannot be managed/interacted with through a RDP session in TP4.
So far I managed to have at least a decent file explorer by using Midnight Commander, but still command line on Windows is not much fun.
in this video MS-container-developer Taylor Brown says that they break up with RDP from TP3 to TP4 and will very probably do not support RDP in RTM Version Server 2016:
https://channel9.msdn.com/Events/TechNetVirtualConference/TechNetVC2016/Day-3-Containers-Session-with-QA
Update as of Dez. 2018:
Server 2019 is out and RDP is still not possible / supported for all container images. (of course it does not make any sense for nano images)
check this nice intro to what has changed: https://stefanscherer.github.io/docker-on-windows-server-2019/
to have a somewhat complete overview, it should be mentioned that there are some hacks out in the wild, that may RDP make work in some images and setups, e.g.:
https://withinrafael.com/2018/03/09/using-remote-desktop-services-in-containers/