I have a Visual Studio Solution that I've been working with. This solution has a console app in it. Notably, I've been running Windows within a Bootcamp partition on my MacBook Pro.
A developer on my team wanted to use Docker. I agreed, thinking it wouldn't impact the console app itself. However, I can no longer compile the console app since Docker has been added. When I attempt to compile the solution, I see:
Visual Studio Container Tools requires Docker CE for Windows. To get it, see https://go.microsoft.com/fwlink/?linkid=847268
For more info, please see: http://aka.ms/DockerToolsTroubleshooting
Here's the problem, since I'm running Windows via a Bootcamp Partition, I can't run Docker (from my understanding). Is there a way to disable Docker just for my myself? If so, how? I don't want to undo what the other dev has done. However, I can't setup a brand new environment at this time.
My need is similar: disable Docker completely, but without uninstalling it.
So, this may help. But
My use case is different: I want to as nimbly as possible switch between VMWare and Docker.
My environment is different: I have a non-macbook PC and I'm only running Windows.
So YMMV.
This worked for my use case:
In the services control panel, disable the Docker for Windows Service or set it to manual start.
On the task manager startup tab, disable Docker for Windows.
For my use case only, there additional changes for VMWare. Disable DeviceGuard and CredentialsGuard per article at https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage.
Hope this helps for you.
Is it possible for this setting to work?
1) Ubuntu 14 with Jenkins, Genymotion, and Virtual Box installed
2) The job inside Jenkins will restore and run Genymotion from a command line following this tutorial: http://blog.genymobile.com/genymotion-jenkins-android-testing/
From my Mac, I tried to access the Jenkins website and run the build.
Firstly, Genymotion failed because it couldn't "connect to X server".
So, I installed Xvnc Plugin on Jenkins which solved the error.
Unfortunately, Genymotion still failed to start up with the error "Cannot get IP address".
Please note that I only have "ssh -X" access to the server.
I can manually start up Genymotion but the process was terminated when I logged off. As a result, I could not leave the GenyMotion run on the Server as suggested by this solution: Jenkins - Use Genymotion VM instead of Android Emulator
Any advice?
Here is the way to make Genymotion works on a continuous integration server.
First, the computer running Genymotion needs to respect the hardware requirements
You won't be able to run Genymotion if you don't have an X server running.
I don't think xVNC supports OpenGL so I advise you to run your standard X server.
You can launch the Xorg server by running startx.
Then you need to set your ssh connection in Jenkins without the -X parameter because we want the rendering to be done locally
Then you need to declare the environement variable DISPLAY to the default X client's value. Most of the time it is :0
This value will ask to open all the windows you launch through the ssh connexion into the first X client. It is the one running on the computer screen.
To check the DISPLAY value you need to enter, you need to access the computer physically and type echo $DISPLAY. Most of the time this value is :0
Also, if your computer is not compatible with the hardware requirements, you can use another computer on your network to run your tests thanks to the Jenkins nodes. Here is a good tutorial to set it up.
And finally, I want to mention we will soon release a command line tool for Genymotion and a Gradle Plugin that will allows you to control your Genymotion devices running during your tests directly from your build.gradle file.
It`s a bit late, but maybe this could help you out
### Get IP address of selected VM
VM_IP=`VBoxManage guestproperty get $VM_SELECTED androvm_ip_management | awk - F ": " '{print $2}'`
I found this here (repo) respectively here (slides)
Description
We are using appium in our cucumber suite within TeamCity 8 on an Apple MacMini running Mavericks. The problem is that appium seems to fail to interact with the iOS Simulator when it is ran from TeamCity at login (via Automator).
The only combination that I have found to work is to run the following from the Terminal in an interactive session:
sh /Applications/buildagent/bin/agent.sh start
What does not work?
running agent.sh start from an ssh session
creating a shell script with Automator that launches at login (the macmini is set to login automatically)
Theory
My theory is that it has something to do with Preferences -> Security & Privacy -> Accessibility. The only way that it works when launching from Terminal is if Terminal is added to this list of allowed applications. I'm not sure what I need to add to this list in order for this to work automatically at login.
Any help would be greatly appreciated.
Many iOS tests will not run without an interactive session. For example, unit tests using the iOS simulator will not work.
Edit: By interactive session, I mean the TeamCity agent must be started from the desktop, not via an SSH session. Otherwise nothing can communicate with the Simulator.
You are correct, you need to allow Appium to interact with Automator.
Solutions straight from the documentation:
If you're running Appium from an NPM install: sudo authorize_ios
If you're running Appium from source: sudo grunt authorize
If you are running Appium.app, you can authorize iOS through the GUI. This prompt pops up the first time you click "Launch/Run" on the GUI and it tries to open the simulator
I've followed the instructions here:
BB10 Cascades Command Line Development
Now I've got a makefile project, which can compile and deploy my application to a connected device. The only problem is, I can't start the application remotely. I've created a special test version, which simply runs an automated test and then quits, so the next logical step would be starting the application, and waiting for it to exit (it would be great if I could monitor stdout and stderr) or kill it if it takes too long.
What I'm trying to accomplish (to avoid the xy problem) is the integration with a Jenkins server we already use for other platforms. E.g.: on Android we use robotium to achieve the same degree of integration.
blackberry-nativepackager allows you to launch the application similar to androids adb.
Just call it like
blackberry-nativepackager -launchApp <path to bar file> -device <devices ip address> -password <your pwd>
I'm currently running Vista and I would like to manually complete the same operations as my Windows Service. Since the Windows Service is running under the Local System Account, I would like to emulate this same behavior. Basically, I would like to run CMD.EXE under the Local System Account.
I found information online which suggests lauching the CMD.exe using the DOS Task Scheduler AT command, but I received a Vista warning that "due to security enhancements, this task will run at the time excepted but not interactively." Here's a sample command:
AT 12:00 /interactive cmd.exe
Another solution suggested creating a secondary Windows Service via the Service Control (sc.exe) which merely launches CMD.exe.
C:\sc create RunCMDAsLSA binpath= "cmd" type=own type=interact
C:\sc start RunCMDAsLSA
In this case the service fails to start and results it the following error message:
FAILED 1053: The service did not respond to the start or control request in a timely fashion.
The third suggestion was to launch CMD.exe via a Scheduled Task. Though you may run scheduled tasks under various accounts, I don't believe the Local System Account is one of them.
I've tried using the Runas as well, but think I'm running into the same restriction as found when running a scheduled task.
Thus far, each of my attempts have ended in failure. Any suggestions?
Though I haven't personally tested, I have good reason to believe that the above stated AT COMMAND solution will work for XP, 2000 and Server 2003. Per my and Bryant's testing, we've identified that the same approach does not work with Vista or Windows Server 2008 -- most probably due to added security and the /interactive switch being deprecated.
However, I came across this article which demonstrates the use of PSTools from SysInternals (which was acquired by Microsoft in July, 2006.) I launched the command line via the following and suddenly I was running under the Local Admin Account like magic:
psexec -i -s cmd.exe
PSTools works well. It's a lightweight, well-documented set of tools which provides an appropriate solution to my problem.
Many thanks to those who offered help.
Download psexec.exe from Sysinternals.
Place it in your C:\ drive.
Logon as a standard or admin user and use the following command: cd \. This places you in the root directory of your drive, where psexec is located.
Use the following command: psexec -i -s cmd.exe where -i is for interactive and -s is for system account.
When the command completes, a cmd shell will be launched. Type whoami; it will say 'system"
Open taskmanager. Kill explorer.exe.
From an elevated command shell type start explorer.exe.
When explorer is launched notice the name "system" in start menu bar. Now you can delete some files in system32 directory which as admin you can't delete or as admin you would have to try hard to change permissions to delete those files.
Users who try to rename or deleate System files in any protected directory of windows should know that all windows files are protected by DACLS while renaming a file you have to change the owner and replace TrustedInstaller which owns the file and make any user like a user who belongs to administrator group as owner of file then try to rename it after changing the permission, it will work and while you are running windows explorer with kernel privilages you are somewhat limited in terms of Network access for security reasons and it is still a research topic for me to get access back
Found an answer here which seems to solve the problem by adding /k start to the binPath parameter. So that would give you:
sc create testsvc binpath= "cmd /K start" type= own type= interact
However, Ben said that didn't work for him and when I tried it on Windows Server 2008 it did create the cmd.exe process under local system, but it wasn't interactive (I couldn't see the window).
I don't think there is an easy way to do what you ask, but I'm wondering why you're doing it at all? Are you just trying to see what is happening when you run your service? Seems like you could just use logging to determine what is happening instead of having to run the exe as local system...
Using Secure Desktop to run cmd.exe as system
We can get kernel access through CMD in Windows XP/Vista/7/8.1 easily by attaching a debugger:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"
Run CMD as Administrator
Then use this command in Elevated:
CMD REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"
Then run osk (onscreenkeyboard). It still does not run with system Integrity level if you check through process explorer, but if you can use OSK in service session, it will run as NT Authority\SYSTEM
so I had the idea you have to run it on Secure Desktop.
Start any file as Administrator. When UAC prompts appear, just press Win+U and start OSK and it will start CMD instead. Then in the elevated prompt, type whoami and you will get NT Authority\System. After that, you can start Explorer from the system command shell and use the System profile, but you are somewhat limited what you can do on the network through SYSTEM privileges for security reasons. I will add more explanation later as I discovered it a year ago.
A Brief Explanation of how this happens
Running Cmd.exe Under Local System Account Without Using PsExec. This method runs Debugger Trap technique that was discovered earlier, well this technique has its own benefits it can be used to trap some crafty/malicious worm or malware in the debugger and run some other exe instead to stop the spread or damage temporary. here this registry key traps onscreen keyboard in windows native debugger and runs cmd.exe instead but cmd will still run with Logged on users privileges, however if we run cmd in session0 we can get system shell. so we add here another idea we span the cmd on secure desktop remember secure desktop runs in session 0 under system account and we get system shell. So whenever you run anything as elevated, you have to answer the UAC prompt and UAC prompts on dark, non interactive desktop and once you see it you have to press Win+U and then select OSK you will get CMD.exe running under Local system privileges. There are even more ways to get local system access with CMD
an alternative to this is Process hacker if you go into run as... (Interactive doesnt work for people with the security enhancments but that wont matter) and when box opens put Service into
the box type and put SYSTEM into user box and put C:\Users\Windows\system32\cmd.exe leave the rest click ok and boch you have got a window with cmd on it and run as system now do the other steps for yourself because im suggesting you know them
There is another way. There is a program called PowerRun which allows for elevated cmd to be run. Even with TrustedInstaller rights. It allows for both console and GUI commands.
(Comment)
I can't comment yet, so posting here... I just tried the above OSK.EXE debug trick but regedit instantly closes when I save the filled "C:\windows\system32\cmd.exe" into the already created Debugger key so Microsoft is actively working to block native ways to do this. It is really weird because other things do not trigger this.
Using task scheduler does create a SYSTEM CMD but it is in the system environment and not displayed within a human user profile so this is also now defunct (though it is logical).
Currently on Microsoft Windows [Version 10.0.20201.1000]
So, at this point it has to be third party software that mediates this and further tricks are being more actively sealed by Microsoft these days.
if you can write a batch file that does not need to be interactive, try running that batch file as a service, to do what needs to be done.
I use the RunAsTi utility to run as TrustedInstaller (high privilege). The utility can be used even in recovery mode of Windows (the mode you enter by doing Shift+Restart), the psexec utility doesn't work there. But you need to add your C:\Windows and C:\Windows\System32 (not X:\Windows and X:\Windows\System32) paths to the PATH environment variable, otherwise RunAsTi won't work in recovery mode, it will just print: AdjustTokenPrivileges for SeImpersonateName: Not all privileges or groups referenced are assigned to the caller.
Using task scheduler, schedule a run of CMDKEY running under SYSTEM with the appropriate arguments of /add: /user: and /pass:
No need to install anything.
i used Paul Harris recommendation and created a batch file .cmd or .bat with what ever command i needed to run under system and used the schedule task run one time.
than trigger it as needed. and updated the batch as needed. so any command i need to run under system i just update the batch.