The question says it all.
Running Windows 10 (home) and googling for the past two hours on running SonarQube in windows10. Everything I came cross talks about running SonarQube in docker.
Anyone out here know if it's even possible to run SonarQube in windows without a container. If it is, how do I do it?
Looks like I can run the server with a Java 11 install.
Once I did that the docs led the way.
Related
I'm trying to run the planet scale cli and the docs said to install mysql,
After I installed mysql shell 8 and tried to run it, it throws:
api-ms-win-core-path-l1-1-0.dll missing
where does api-ms-win-core-path-l1-1-0.dll come from?
and how do I add it?
Windows 7 64bit, powershell 2.0 , windows .net framework 4
I filed a mySQL bug report and this is what they said:
Thank you for your bug report.
However, this is not our bug.
This is a missing Windows system library. You can read more about that
here:
https://wiki-drivers.com/du-101/?m=src_evp_adwords_du_dll_e&build=ppc&content=ppcdudll&build=ppc&kw=api-ms-win-core-path-l1-1-0.dll&gclid=EAIaIQobChMIl6LTgbjJ-wIVmeFRCh1KvwH_EAAYASAAEgJWwvD_BwE
alternative solution would be to try upgrade to PowerShell 5 and install via scoop or something of that nature
I've yet to try this solution due to my windows 7 laptop's screen messing up causing me to upgrade my laptop.
Thought it would be helpful to follow up with my findings
I'm on windows 10 and I'm encountering Docker on Windows crashing on startup.
I just installed docker on windows and have a couple of containers spinning up (last night). I've been able to use it but after reboot, or shutdown, this was the behaviour ever since. Pretty unstable.
It looks like this and terminates after a while without any prompt of an error.
More info that I have Hyper-V installed on my machine and "Use the WSL 2 based engine" option enabled on docker.
On my end, I was able to solve this by:
Going to Apps & Features
Search for Ubuntu (or any linux distro you've installed)
Click on it and navigate to Advance options
Click on Reset button.
Also, try to trial and error which docker on windows version is stable with your system.
Hope that helps.
Hoping this is the right place to ask this. I'm trying to learn React Native and I'm using Expo as my medium for deployment, but I'm finding that I'm literally getting 20 minutes at a time before my browser fails to connect with the error code ERR_CONNECTION_FAILED. I've tried the following:
netsh winsock reset, then the related ipconfig commands for flushing DNS settings
Clearing browser caches
Updating drivers
I'm at my wits end as the only thing that completely solves it is restarting my laptop, which for obvious reasons isn't feasible every 20 minutes, so I'm hoping somebody can help.
I'm experiencing the same issue with Expo in this environment:
Windows 10, version 1909 (OS build 18363.476)
using WSL (Windows Subsystem for Linux) with Ubuntu 18.04 LTS
These links were useful to learn why this is happening:
https://github.com/expo/expo-cli/issues/99
https://github.com/microsoft/WSL/issues/2913
https://github.com/microsoft/WSL/issues/3951
In essence, this issue seems to be due to a problem with WSL. Per a post in the first link, I tried the alternative to restarting the computer and it worked - it made the ERR_CONNECTION_FAILED problems disappear...for 20 minutes. That alternative is as follows:
WIN+R -> services.msc
Find LxssManager
Right-click -> Restart
This restarts the WSL service which also means that the WSL instance that was running gets terminated. This is less than ideal, but at least a computer restart is avoided. The third link says this WSL problem is fixed in Windows Insider Build 18890.
I am now considering spinning up a VM to run Ubuntu instead of trying to use WSL for Expo projects.
I uninstalled the latest Windows updates, and the problem has not surfaced since.
I have been developing and maintaining some windows on windows Docker containers that run ASP.NET core applications on Windows 2016 (using Docker EE) for some time now. I was planning on turning over all ongoing updates/maintenance to server administrators, but I have hit a problem. When I started I believe I was using SAC builds, but now none of the SAC (or LTS for that matter) builds pull on Windows 2016, and though I have spent a good deal of time googling, this whole thing seems to be a big cluster. With docker on Linux, I would just use any LTS distro and apply updates when building the container. Does Microsoft have a clear plan on doing the same? It seems like they are missing the point of docker. I want to run a windows on windows container in windows server 2016, and I want to make sure when I recreate it that I am getting the latest security updates.
https://devblogs.microsoft.com/dotnet/net-core-container-images-now-published-to-microsoft-container-registry/
This page talks about the big changes made in Docker images recently and specifically says the following:
.NET Core images for Nano Server 2016 are still available on Docker Hub and MCR and will not be deleted. You can continue to use them but they are not supported and will not get new updates. If you need to do this and previously used manifest tags, like 1.1-sdk, you can now use the following MCR tags (Docker Hub variants are similar)
Does this mean the new tags listed get updates? I would assume they would tag it with LTS instead of SAC2016 to better convey the notion that they are continuing to update.
This page seems to be really helpful, but none of the images listed pull on windows server 2016:
https://andrewlock.net/exploring-the-net-core-mcr-docker-files-runtime-vs-aspnet-vs-sdk/
This is what I get when I attempt to pull any of the images:
1709: Pulling from windows/nanoserver
no matching manifest for unknown in the manifest list entries
To clarify, I can currently run all my applications using such images as these:
mcr.microsoft.com/dotnet/core/runtime 2.2-nanoserver-sac2016 4a3bbafea836 3 months ago 1.27GB
mcr.microsoft.com/dotnet/core/sdk 2.2-nanoserver-sac2016 9773d80bdd64 3 months ago 2.62GB
I am looking for clarity on support of these images, or a clearer direction to migrate.
Right now, for LTS, the image you want to pull is: mcr.microsoft.com/dotnet/core/aspnet:2.1. Since 2.1 is the LTS release of ASP.NET Core. The underlying server reference doesn't matter, honestly, and all the .NET Core images are multi-arch, so the right underlying images are pulled automatically (linux for linux host, Windows for Windows host, and AMD64, x86, ARM, etc.).
The OS of the image (aside from being the right architecture and platform) is really kind of meaningless. It's mostly a translation layer. Images aren't VMs, the OS is on the host, and that's where your security patches and such apply. As long as your host is patched up, you're good.
UPDATE
This has apparently led to some pedantic arguments in the comments, so let me be a little more clear. What I'm talking about here is best described via this graphic from the Docker site:
Whereas a VM has a copy of the OS on each instance, containers utilize a shared host OS. The OS base image is basically a proxy. It provides the API, but everything at an OS-level happens on the host OS, not in the container.
As such, yes, the OS base image matters to a certain extent. You can't target a Linux base image and deploy to Windows Server. You'd have issues targeting Windows Server 2019 and deploying to 2016, as well. However, assuming that the OS base image is remotely compatible with the host OS, then everything above and beyond that is meaningless.
Specifically to the discussion of patches and LTS versions, you don't need to care, because again, what's actually running is components of the host OS, not anything from the image itself. You can actually see this if you open Task Manager on the host OS. You'll see duplicate system-level processes tied to each running container. Even though the container shows running processes as well, it is these host-level processes that are actually doing the work, and therefore, it is only important that they are patched and supported. If everything is good on your host, you need not worry about the containers, at least for the OS part of things.
https://github.com/docker/for-win/issues/3761
I was working around Mar 12 when all the docker pulls stopped working because of the changes MS did. So I am sure I saw this page before, but on rereading the entire thing again, I see this comment:
docker pull mcr.microsoft.com/windows/servercore:ltsc2016
That seems like a reasonable tag name for long term support. Lo and behold it works. I am currently theorizing that nanoserver is only for the latest and greatest, and am thinking of opening an issue on github to see if someone will answer that definitively.
I think one of the comments on that page from the github maintainer settles the debate in the Chris Pratt's answer. I think mis-information floating around about security is dangerous, so I am reposting here to help future souls who stumble on this question:
Yes, when running with process-isolation, the version must match the Windows kernel version you're running on. Unlike Linux, the Windows kernel does not have a stable API, so container images running on Windows must have libraries that match the kernel on which they will be running to make it work (which is also why those images are a lot bigger than Linux images).
Vulnerable libraries in a docker container DO matter. You cannot rely on the host OS being up to date to protect you.
Further Research
Still researching this, so adding my updates for your benefit as I find them:
Article about Migrating
https://www.altaro.com/hyper-v/nano-server-no-longer-supported-for-infrastructure/
TLDR - Move to servercore
Server 2016 14393 Tags on Docker Hub
The main docker hub nano server page does not list any 14393 tags, but visiting the full tags list at the bottom of the page shows many. I was able to pull mcr.microsoft.com/windows/nanoserver:10.0.14393.1066 and it is only 1GB instead of 14GB for server core
I've built an Electron app using the Squirrel packager/update manager.
I've had no issues in building the bundle, targeting Windows 64bits only.
I installed it on my Macbook pro (on a windows 7 x64 dual boot) without trouble. I tested it also on a 64 bit Surface pro 3 (Win 10), and another Win 7 PC. Everything works fine.
I published the app and got a few hundred downloads :half the people that downloaded it has it working, and for the other half it just won't start. The process spawns, then dies a second after. I tried starting it in admin, the admin dialog box won't even show. I tried running it from command line
myapp.exe > out.txt
But out is empty. How can I debug this ?
I was having trouble getting the logs for a production build as well.
My solution was to use electron-log to let the production app write logs to disk while debugging the problem.
You can then access the logs on windows at:
%USERPROFILE%\AppData\Roaming\<app name>\log.log.
Add some logs in your app that will give you insights in where the app crashes.
Don't forget to remove electron-log when you're done debugging and don't need to write any logs to disk any more.
I solved it for many users by building directly on a windows 10 fresh install.
The builds I used before were built on a windows 7. Not sure if it was that, I also have been cleaning the node modules a little bit, so maybe one of the modules I removed was the issue. Anyways, I still do not know of to debug the built exe in this kind of situation. There must be a way to get a log or something when the process kills itself