I'm writing a Windows application that interacts with a WSL distribution/instance which has Docker running. Also, in some cases, my application will also run commands/processes directly in the WSL/Linux distribution.
I would like for that WSL distribution to be "managed" by my application. By that, I mean that:
The distribution should be installed by my application so that users don't have to have knowledge of WSL itself. If the users have to install the WSL distribution themselves, it's entirely possible that they could misconfigure it. It's also possible that some users might not be able to get it up and running in the first place.
The user should have no control over my application's managed WSL distribution. They would not be able to:
Shutdown the instance when it is running under my application.
Uninstall the instance without uninstalling my application.
Preferably the user would not even see the distribution at all.
Can I create/install a distribution that is managed by my application in this way?
It's obvious that I could simply run a batch script, import the instance, and then just run it like that. But this seems verbose and, as mentioned, would still be visible to the end user.
Well, I definitely can't offer you a direct answer that meets those requirements, and I don't think it's possible, at least not currently.
WSL distributions are always visible to the end user. And they can always be --terminate'd or even --unregister'd. Even Docker Desktop's distribution are subject to these limitations.
You can see the Docker Desktop distros with wsl.exe -l -v, returning something like:
NAME STATE VERSION
* Tumbleweed Stopped 2
...
Ubuntu-22.04 Running 2
Artix-dinit Stopped 2
docker-desktop Stopped 2
docker-desktop-data Stopped 2
...
side-note: I have entirely too many distributions ;-)
But ... Docker Desktop does overwrite the distro with a new version when you upgrade, so any changes to it will (at least eventually) be overwritten.
So that does provide a possibility:
Ship your managed distro in tar form in/with your application.
When starting the application for the first time, create (--import) the distribution from the tarball.
Make sure that nothing in the distribution writes to/modifies the filesystem. You might could even set it read-only in some way, but I haven't tried that.
Perform a checksum of the distribution vhdx when starting each time, and confirm that it hasn't been modified.
If it has been modified, then delete it and re-import.
Alternatively, as mentioned in the comments, there may be a way to do this with a Hyper-V VM (but only, of course, on Windows Professional or higher). The WSL2 VM itself is hidden and managed in some way, and the same appears to be the case with BlueStacks.
I'm still not sure how they do this. From watching the Event Viewer, it appears that a new Hyper-V "Partition" is created when starting WSL2. This does not appear to be related to any "disk partitioning", so I believe that it is some type of Hyper-V partition that is hidden from the user.
Related
I need some straight answers about this as the current docker info and general Web info mixes hyperv and vmware info up.
I have installed docker on my windows 10 pro machine. I do not have vmware/virtual box installed I don't need it I have hyperv? I can use docker on a Linux Ubuntu box fairly well and I (think!) I understand volumes. Sorry for the background...
I am developing a node app and I simply want to have a volume within my Linux container mapped to a local directory on my windows machine, this should be simple but everytime I run my (lets say alpine linux) container '-v /c/Users:/somedata' the directory within the Linux /somedata directory is empty?
I just don't get this functionality on Windows? If you have a decent link I would be very grateful as I have been going over the docker info for two days and I feel I am nowhere!
If volumes are not supported between Windows and Linux because of the OS differences would the answer be to use copy within a Docker file? And simply copy my dev files into the container being created?
MANY MANY THANKS IN ADVANCE!
I have been able to get a link to take place, but I don't really know what the rules are, yet.
(I am using Docker for windows 1.12.0-beta21 (build: 5971) )
You have to share the drive(s) in your docker settings (this may require logging in)
The one or two times I've gotten it to work, I used
-v //d/vms/mysql:/var/lib/mysql
(where I have a folder D:\vms\mysql)
(note the "//d" to indicate the drive letter)
I am trying to reproduce this with a different setup, though, and I am not having any luck. Hopefully the next release will make this even easier for us!
Thank you in advance for considering this question. If a similar question existed, I was unable to find it.
The Issue: Our company packages an application into an MSI. This MSI when installed outside of any GPO properly updates, blocks attempts to downgrade (or move from a higher revision to a lower revision), and never has trouble uninstalling previous versions of the application regardless of how long ago those versions were created/installed. For example, we can install version 1.2.3 and then install version 2.3.4 and the application will properly install without issue. However, we work with a customer who uses GPO to deploy our application to hundreds of PC's. Each time we have provided an updated version of the application the following has been indicated:
On any machine where a previous version of our application was installed via GPO, no matter what the previous version is, the update successfully installs without issue.
On a machine where the application was manually installed (outside of the GPO), and an attempt to update the application via GPO is made - either the application is installed in addition to the old version, OR there remain registry keys to the previous version of the application and the application cannot open/run correctly. In this case the registry keys must be manually removed, and the install is then attempted again from a clean machine.
What we know is that on any machine where the application was originally installed via GPO - updating the application is no problem. On every machine where the application was not installed with the GPO in the first place, updating via GPO fails with one of the problems presented above.
My question is: Is there a technical issue with how the installation is being handled partially through the GPO and partially outside? Does the GPO need to be responsible for the entire life-cycle of the application? OR is it a reasonable expectation that the application be updated both on machines where the original version was manually (outside the GPO ) installed, and when it was installed initially from within the GPO?
One solution we are aware of is simply having all computers manage the application life-cycle (since we know updates work in that environment already), however this would mean that many computers would need to have the manually installed versions removed by hand - and then properly handle the installation through GPO which is an extensive bit of work.
We would greatly welcome any solutions, references to technical documentation that formally shed light on the proper management or expectations here, or links to information. Our research suggests that it is "best" to manage the entire applications life-cycle inside the GPO - but I have as of yet been unable to determine that it is 100% necessary to do so.
Looking forward to any assistance. If any further technical details are required to help the viability of the question, please don't hesitate to request such details.
If you end up with two versions installed in Control Panel, then all other things being correct, the most likely explanation is that you upgraded a per user install with a per machine install (or vice versa). In the GPO world that's related to assigning it to a user or to the computer, something like that. That's easy to verify by getting a verbose log and checking the FindRelatedProducts actions for an indication that another product was found but in a different context.
When you're in GPO mode all the time, I assume each one (whether it's per user or per machine) is consistent, therefore upgrades always work, but they don't work cross-context.
I believe GPO suppresses the UI in most cases, and the UI (or the UI sequence) is sometimes where per user/per machine is set. That might be something else that would cause it, depending on how the GPO publishes to the computer or the user.
I created a Visual Studio 2010 installer project and added the postgresql-9.2.401-windows.exe file to it. In the "Commit" custom action, I added that file, removed any arguments and set InstallerClass to False.
Now, when I run my application's installer, the PostgreSQL setup starts up, shows its splash screen and then jumps to 100% CPU usage and starts leaking memory for a long time (certainly longer than a few minutes), after which it bails out. Running the .exe on that computer works just fine.
How should I package PostgreSQL in my installer?
Personally I don't like programs that silently install the standard PostgreSQL for Windows. It's deeply annoying to get mailing list posts from people who're asking "What's this PostgreSQL thing and why is it using 88 bajillion megabytes of RAM, I didn't ask for it, remove it now!".
(Yes, I'm mostly talking about a certain annoying gambling card-counting program with the initials PT whose name I will not mention directly).
If you're going to bundle PostgreSQL it'd be great if you could use a non-default port and non-default data directory. If you install a service to auto-start it, don't use the default service name postgresql-[version] but something like myapp-database or myapp-postgres.
This is all done much more easily if you just bundle the PostgreSQL binaries in your installer then create the service yourself with your installer tools or via sc.exe. You may choose to simply pg_ctl start/stop the server from within your program, though this requires some thought about access permissions to the data directory.
The downside is that when there are PostgreSQL updates you need to update your installer. On the other hand, you probably don't want people upgrading PostgreSQL independently of your software updates.
I suggest using the .zip binaries from here and bundling them into your installer directly.
If you really must use the executable installer the documentation contains instructions on silent installation.
I am trying to create an application that runs on windows. I want this application to download a "disk image" from the network (from pre-assigned server) and create a virtual machine based on it. This VM would run for a specified number of hours and then shutdown.
I want to use VirtualBox by scripting it. I found VBoxManage command and it seems to be what I am looking for. However, it seems that VirtualBox tools store their configuration as XML files in User home directory. I did learn that i can change the value of VBOX_USER_HOME environment variable to control where they are stored. However, I am not sure whether this is enough.
My problem is that the user may already have installed VirtualBox on his/her computer. I do not want my application code (and it's packaged VirtualBox binaries and conf) to mess with the existing installation.
How do I cleanly isolate my application specific VirtualBox binaries and configuration from the potentially pre-existing installed VirtualBox setup? (Even if both instances of VirtualBox binaries are being used at the same time)
I chose VirtualBox because of it's open source license and applicability of commercial use (if I compile my own binaries from the source) and because it works on Windows too (heard QEMU support for windows is still not stable). Will VirtualBox suffice for my use-case or should I look elsewhere?
Thanks for reading so far :)
If the VBoxManage command really does rely on the environment variable VBOX_USER_HOME then you could write your scripts to change the environment variable to reflect your deployment for the execution of that script and its children, staying away from user data.
Check out the VirtualBox SDK http://download.virtualbox.org/virtualbox/SDKRef.pdf
I have an application (Installed as a service) that has 5 different versions. For testing I need to have all 5 installed. Currently I have to uninstall the application and reinstall the required version.
The application has a single exe (in Program Files\App) along some an xml file containing it's settings. This is installed via an MSI file. Each version has the same file\service name and checks for previous versions before installing.
Any ideas on a way to run all five versions at the same time?
First of all, I assume you're a developer, not the QA person. The QA need to use either virtual machines, or just 5 separate PCs. What I'm describing is a dirty hack that might save you some time.
Install version #1 to C:\program files\YourApp_1
Launch services.msc, stop the service, change the startup type to manual.
Launch regedit.exe.
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services key, find the key for your service, rename the service: change both the key name, the "DisplayName" value, and to simplify your life write something meaningful to the "Description" value, e.g. "MyApp 1.0 - this is the reference version".
If the installer checks some other keys before installing (it might be e.g. in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\YourApp), remove them. If you don't know those keys - use SysInternals ProcessMonitor to get them (set filter to instmsiw.exe or something, then launch the installer, wait for the "the prevoius version was found" message, alt-tab to the ProcessMonitor, stop logging, and read the log bottom-to-top)
Now install version #2 to C:\program files\YourApp_2, repeat the process.
At the end, to switch versions you'll only need to launch services.msc, stop the version that's currently running, start another one. Or use net start / net stop command line commands. Or whatever.
P.S. Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
Though this is more of a Sever Fault type of question:
http://www.microsoft.com/windows/virtual-pc/
There's yer answer :-)
Use virtual machines for each of your 5 different versions.
VMWare player is free: http://www.vmware.com/products/player/
Use VirtualBox.
Create one test system, configure it, then clone it 5 times (you'll have to use vboxmanage), and install one version on each of them.
If it wasn't a service, I had suggested Sandboxie, but I doubt that Sandboxie can handle services.