Some of my builds and plugins make use of private deployment credentials (sometimes read from the file system, sometimes entered and retained in memory via the InteractionService).
Though perhaps it is overparanoid, I try to be careful to minimize the attack surface of software that uses private information, and it feels like bad hygiene to run a server, even on localhost or a UNIX socket, unnecessarily in these builds.
I've looked for a setting I could set in a plugin that would disable server startup unless overridden by the build. So far have not found anything like this. Is there such a setting?
Many thanks!
Update: With the help of Eugene Yokota, as of sbt 1.1.1 there is now a boolean autoStartServer setting. Builds and plugins can prevent the server from starting up automatically by setting autoStartServer := false. (Users can still manually start-up the server by running startServer if they wish.)
As of sbt 1.1.0 at least, the server won't start unless you start the sbt shell, which means that if you're running sbt in batch mode (for example sbt test) in CI environment, it won't have server.
To stop server even in the shell automatically, I've added a JVM flag sbt.server.autostart. So running sbt as sbt -Dsbt.server.autostart=false would do it. You can globally set that by putting that into your SBT_OPTS.
To manually opt-in for server, you can then run:
> startServer
Update: Now that autoStartServer is a setting, you can write the following in ~/.sbt/1.0/global.sbt:
// This is so it works on sbt 1.x prior to 1.1.1
SettingKey[Boolean]("autoStartServer", "") := false
Related
Learning apache airflow and I'm trying to create a new connection type the correct way, but it still doesn't show up. I am working within a virtual environment on WSL2 through VS Code, and my terminal looks like this (sandbox) nick#GameCube:~$
This is what my pip list within the venv shows
But these are my only conn types within the airflow UI (I am running airflow webserver within the venv too)
You can see that all the other installed conn types show up, but http doesn't for some reason. Why does this happen? I have tried restarting vscode, killing the webserver process and restarting it, etc but it still doesn't show!
The apache-airflow-providers-http==4.0.0 is not compatible with apache-airflow==2.1.0
To solve your issue you need to downgrade http provider to a version compatible with Airflow 2.1.0
Noting that Http provider is installed by default with Airflow if you need to bump its version make sure you set it to compatible version.
In larger context I suggest to install Airflow from constraints as suggested in the docs. This will prevent case of unstable environment as Airflow brings many dependencies and it guarantees a working environment of Airflow. You can upgrade providers to newer versions but you will need to take a closer look on each upgrade. You can read about it in this doc: Installing/upgrading/downgrading providers separately from Airflow core.
I have a simple application using
QT += core gui network webkitwidgets
I've used windeployqt.exe to generate the 32 bits release on my win-10 64 bit computer. When I put the folder on a win-7 64 Bit desktop and double-click the app.exe, it never starts.
I can see it in the task manager, but I can't kill it, and if I try I cannot close the explorer folder in which I double clicked anymore.
I've checked the usual platform, ICU, qwindows.dll, and so on.
http://doc.qt.io/qt-5/windows-deployment.html
EDIT Precisions:
I've compiled with default 32 Bit kit: "build-Test-Desktop_Qt_5_5_1_MinGW_32bit-Release" with "mingw492_32"
I have a package "release" generated by windeployqt.exe using the --webkit switch. I start a command prompt:
> set path=
> set mingw=
Then I make sure that no Qt/Mingw things exists anymore in my environment variables.
I also rename "c:\Qt" into "c:\ __Qt".
I move my release folder on my desktop.
I start release\test.exe ( from the clean path shell )
Everything runs fine! So The release/test.exe has everything it needs without the path/mingw variable.
But as soon as I put the folder on another windows machine ( 7 instead of 10 ) it never starts.
I tried dependency walker. It shows a lot of "API-MS-WIN*.dll" missing...
It even shows much more missing dlls on the "good" machine than on the bad one !!!
Every single "missing dll" on the "bad" target machine is actually in system32 on this machine.
Thanks for advice, every advice is welcome, I'm a bit desperate... :)
Edit
It seems to be related to the machine itself. I have successfully deployed this (very small) app to 2 non developer machine on win7 and win8 respectively. But the above "bad machine" still resits running it...
Edit
The problem seems not to be general but related to this one particular machine. Hence, feel free to close or move to the appropriate forum as it is not related to Qt/windeplyqt. If I figure out a solution, and question is closed, I'll simply add a last edit. Safe Boot and malwarebyte are my next actions.
After a long investigation.
Do not believe dependency walker, it used to be a top notch tool but it is now outdated.
If there is a missing dll, the system will prompt you with "cannot load dll xxx.dll" anyway.
Your best shot in case a soft runs on machine X but not on Machine Y is:
start in safe mode ( run: msconfig --> diagnostic startup )
turn off any antivirus or non microsoft/driver software,
"run as administrator".
If you can run with step 3. Then proceed by elimination:
run without admin rights,
Start anti spyware, etc...
Add appropriate exception to your antivirus if it is the root cause.
If the antivirus is not the root cause, run process monitor on both machines. Then compare, what Failed on one machine and not the other ? Read the windows event log and compare any error messages on both machines.
run sfc /scannow to check disk
run a complete anti spyware scan/ pc-repair tool ( malwarebytes, combofix, ... )
Make sure you really have the very same package on both machines, make sure you are not trying to run an exe on mac OS, make sure your computer is on.
Call the oracle, you are in the matrix...
In my case the problem was Avast and it was solved by adding appropriate exception.
I've run into an issue with Saltstack version 2014.7.0, where I cannot get network information from Salt.
If I run:
salt-call network.ip_addrs
I get:
Function network.ip_addrs is not available
This only seems to happen on some of my hosts. It seems to effect the almost all of the functions in salt.modules.network, but everything else works as expected.
I suspect there's something in my environment to blame. I am running salt within a CentOS 7 docker container. I followed these instructions to get Systemd running under Docker, and it seems to be functioning just fine, so I don't think that's the issue, but I wouldn't be surprised if it's related. I'm using Docker as a development environment, but I will be using these formula to orchestrate virtual machines in production.
Has anyone encountered the network module not being loaded properly? Is there something that needs to be available for that module to be accessible?
I have other mechanisms to get the IP address, but none that are as easy to work with in other salt formulas.
It turns out my problem was that I had my own custom module called "network" which was obscuring the upstream network module.
I'm pretty sure this was working at some point in the past, so I'm wondering if there might have been a change to salt in a more recent version that would cause it to conflict at a module level instead of merging methods from different modules of the same name, but I suppose it's possible that it never worked.
I often run a dispatcher server in sbt ~run.
unfiltered.netty.Http(port)
.handler(plan)
.run()
Http.shutdown()
When I start up my server, it says:
Embedded server running on port 8080. Press any key to stop.
However, only ENTER will stop the server. Unfortunately, ENTER also stops sbt. How can I set up unfiltered so that it actually stops on any key within sbt? I would like pressing a key to stop the server and cause sbt to re-compile and re-run the application.
You can do continuous hot reloading using sbt-revolver and JRebel. There's a free license of JRebel for Scala users.
Start sbt shell.
reStart starts a forked JVM that's exit trapped.
If you installed JRebel correctly, compiled classes from ~products would get loaded into the forked JVM.
See Hot Reloading.
I have an update function in my app - it downloads and verifies the installer (a setup.exe, created with NSIS). To actually kick off the update, I have simply been doing:
QString path = .. absolute path to the downloaded file ...
QProcess::startDetached(path, QStringList());
This works fine on XP - but on Vista and Win7, nothing happens once the download completes. If I browse to the downloaded update and run it manually, it works fine. I assume what's happening is that UAC is blocking the installer at CreateProcess time, but this is where my knowledge runs out.
Additional complication - when I'm running a debug build from the command line, the steps above work - I get the UAC prompt and can run the installer. It's the release builds, started form the start menu/shortcut, which have the issue - I assume there's a difference in the auth token when running from a command shell.
You can also use
QDesktopServices::openUrl(QUrl::fromLocalFile(path));
Might be surprising and counterintuitive, but it works and is more cross-platform
If you are not admin and you call CreateProcess() on a .exe with a "Vista" manifest (or no manifest, but a .exe that windows detects as an installer (This includes NSIS)) the call fails, you need to use ShellExecute[Ex](). ShellExecute will trigger UAC prompt if required...
This seems to be a Qt bug, see QTBUG-9761 , the correct workaround is to use ShellExecute with lpOperation set to runas.
Another alternative is to prepend your execution with cmd.exe /C. This effectively routes your execution through the shell, so you do get the UAC prompt. The downside is that if your process fails you probably won't get as much information had you gone through ShellExecute[Ex], but on the plus side you will get all the facilities of QProcess that you miss if you use QDesktopServices::openUrl, where you have no idea if things worked or not.