I am running one process and authenticating each request using PAM interface from LINUX user database. it is working fine,
But when running same process under Valgrind, authentication is failing,
All process are running as SDL user and even when running process with Valgrind, then also all process running as SDL
Can Some help, why does authentication is failing when process run under valgrind.
Related
I'm trying to run Selenium tests on Azure devops.
I'm using self hosted agent. I've run the agent interactively. the agent is configured to run as USER1
Now when I run the pipeline the tests are running fine. When I try to view the running tests by rdp into the machine I am able to view them as well.
However when user2 runs the pipeline, the user is unable to see the running tests, but user1 is able to see the tests.
How can we configure the agent so that, any user (user1, user2, user3) that runs the pipeline should also be able to view the running tests when they rdp into that agent which is running the test
When your UI tests run, applications and browsers are launched in the context of the user specified in the auto-logon settings. So other users can not see the running test.
If you use Remote Desktop to access the computer on which an agent is running with auto-logon, simply disconnecting the Remote Desktop causes the computer to be locked and any UI tests that run on this agent may fail.
Check here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/test/ui-testing-considerations?view=azure-devops&tabs=mstest#visible-ui-testing-using-self-hosted-windows-agents
I am running an Azure Pipelines (DevOps) pipeline that builds my automation test solution into a dll, and loads that dll to get all of the integration automation tests.
I am using the default cloud "Host" agents to run the automation. However, the drivers throw tons of errors. I recognize the errors as the same ones that I encountered when I set up automation via Jenkins -- when I was running Jenkins as a service.
To fix the issue in Jenkins, I stopped running it as a Windows service, and started launching it as a java -jar Jenkins.war command in Powershell. That allowed the selenium drivers to launch browsers as normal on the VM's desktop, rather than running the browser instances and drivers completely in memory.
So, when it ran the browser windows and drivers completely in memory, I received the same driver errors as I am now encounting on the Host agents in Azure Pipelines. The problem is that I cannot find how to make the Agents run the tests on the VM desktop. I don't have any idea where to start on solving this problem, and can't seem to find any info online about this.
Edit: To be as clear as possible. The ONLY error occurring is "$ is not defined". This is because the DOM does not load properly because the browser executables and driver executables are running completely in memory, headless. I need to be able to run the executables in a rendered part of the host machines. So, what I mean is, if I were to remote desktop into this machine, I would actively see browser windows rendering, and automation running. Right now though, if I were to remote into this VM, I would see chrome.exe, and chromedriver.exe in TaskManager, but nothing would be visible on the desktop.
I found the answer.
https://learn.microsoft.com/en-us/azure/devops/pipelines/test/ui-testing-considerations?view=vsts&tabs=mstest#visible-ui-mode
You must manually configure the hosts to run Selenium non-headless. This will prevent everything from running as a service, which is purely in memory, with no UI components. This is the problem I mentioned that Jenkins encountered when running Jenkins as a service.
The fix for Jenkins running automation with a GUI is the same for the Hosted agents in Azure pipelines, ultimately. It's just a manual configuration. This is done via a plugin and build step in pipelines.
We are attempting to do our testing remotely, so we set up some Virtual Machines to run our GUI tests and to free up our local machines. What we were hoping for was to have the tests run just like they would on a physical machine, however they seem to require an active Remote Desktop Connection up in order to run properly. These tests are written using LeanFT and it is a windows app so this is not mobile GUI testing.
Is there a certain way to configure this VM to set it up properly for automated GUI testing that does not require an active Remote Desktop Connection? It seems as if its sharing the controls on our physical machine..
Or am I completely wrong here.. Is a Remote Machine different than a Virtual Machine? Thanks!
It's possible to run a GUI test without an active Remote Desktop Connection
I achieved this with leanft through the following 2 steps:
Configure how you execute your tests
Whether you're running via a Jenkins slave or through another kind of "listener" (maybe ssh, or bamboo, etc.), you need to configure this listener to start after a specific user is logged on.
In my case I was running through the Jenkins slave, so I've configured the startup of the slave to launch as soon the user logged in.
Tell windows to login the user when the computer starts. You can achieve that via the following registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DefaultDomainName"="DOMAIN"
"DefaultUserName"="USERNAME"
"AutoAdminLogon"="1"
"DefaultPassword"="PASSWORD"
The core requirement is that you need to have an active session (regardless of whether you are using Jenkins, TeamCity, Grid or other tools to launch the tests).
For your virtual machine, you will need to have access to the console. For VMWare vSphere, there is a native client or website. For VMWare Workstation or VirtualBox, these automatically display.
Using the console access, log into the system and set it up to never log out or sleep or hibernate. This is a variety of OS settings that you can look up.
Essentially, these boxes need to always be logged in. With this setup, you need to be sure access to these systems is controlled so that you don't have random people logging in / or logging out.
I have a jenkins agent set up on window 7 and a jenkins server on Linux. I am running GUI testing on the windows agent. It runs fine if I have a remote desktop connection connected to it, but fails otherwise. I found this link, Jenkins on Windows and GUI Tests without RDC
But the solution provided there is pretty vague.. It seems like the only solution is to somehow make Jenkins server to have a remote desktop connection open at all times. But I can't find such an option to do so.
Could anyone please clearly teach me how to solve this issue?
Much appreciated!
Your slave machines have to be at a desktop before the test can run
properly. We had the same problem.
Solution was to have the test machine start up and auto-logon to the
desktop. To ensure that the test would ONLY start after the desktop
was available, we added a scheduled task, set to run at user login,
that would launch the Jenkins slave via Java Web Start. That way,
Jenkins would only see the slave once the desktop was running. After
that, everything worked fine.
This is the winning answer to the question you linked to and it is very clear on what to do. The whole setup is outside of Jenkins. Jason Swager discribed on how he automated a user logging into a windows desktop machine and then starting the Jenkins slave in the user session.
And now Step by step:
1. make sure you have a GUI evailable
Solution was to have the test machine start up and auto-logon to the desktop
Configure a standard Windows desktop to login a specific user automatically when windows start. This way nobody needs to physically log into the desktop. (see How to turn on automatic logon in Windows 7)
2. start Jenkins slave
You need to start the Jenkins slave within this user setting. Otherwise, the Jenkins slave won't have access to the Windows UI components (or in other words can not interact with the desktop).
To ensure that the test would ONLY start after the desktop
was available, we added a scheduled task, set to run at user login,
that would launch the Jenkins slave via Java Web Start.
So you have to create a scheduled task and configure it to start your Jenkins client using Java Web Start.
3. use it
That way, Jenkins would only see the slave once the desktop was running. After
that, everything worked fine.
When the slave is online, you can use it to run your UI tests.
To solve it, set Windows Auto-Logon as I explain here:
https://serverfault.com/questions/269832/windows-server-2008-automatic-user-logon-on-power-on/606130#606130
Then create a startup batch for Jenkins slave (place it in Jenkins directory), which will launch it's console on desktop, and will allow GUI jobs to run:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be downloaded from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
EDIT :
If you're getting black screenshots (when using Selenium for example), create a batch file that disconnects Remote Desktop, instead of closing the RDP session with the regular X button:
%windir%\system32\tscon.exe %SESSIONNAME% /dest:console
The following thing did the trick for me:
In Jenkins execute windows shell command:
cmdkey /generic:TERMSRV/<servername> /user:<username> /pass:<password>
mstsc /v:<servername> /w:<width> /h:<height>
cd <path to your pom.xml>
<maven command>(e.g. mvn test -Dfiles_to_run=groupLaunch.xml
cmdkey /delete:TERMSRV/<servername>
It creates real mstsc session (Win-to-Win) with specified width and height in your virtual mstsc session (Jenkins-to-Win) powered by Jenkins.
I tried the solutions provided here but nothing worked for me. At the end, I came up with a workaround.
I opened an RDP connection to the VM in a different VM (VM2).
I left the first connection open inside VM2 and disconnected from it.
It worked but that implies having two virtual machines available.
You still need to use RDP but in my case, we can use loopback of the RDP in same VM.
The procedure:
In a VM, create two different accounts, and create Jenkins slave for both of account.
Now you'll have two Jenkins slave for two accounts in one VM
slave 1 - account 1
slave 2 - account 2
Enable multiple RDP follow guide
https://www.serverwatch.com/server-tutorials/how-to-enable-concurrent-remote-desktop-sessions-in-windows.html
In slave 2(with account 2), run rdp command to connect to slave 1(with account 1), like following
Start /b "" "C:\RDP\rdp.exe" /v:127.0.0.2 /domain:\ /u:admin /p:xxxx /fullscreen /w:1920 /h:1200
127.0.0.2 is very important, it's a loopback connection for RDP
Put above command into Jenkins job with the name such as "OpenRDP_ToVMXXX, and then you can run any test on slave 1 with GUI enabled, enjoy.
As the solutions above seemed a bit overkill, I used this approach:
Disable Jenkins service
Start Jenkins from command line using java -jar C:\Program Files (x86)\Jenkins\jenkins.war
For some reason I had to install all plugins and everything when starting it this way, so I recommend creating a backup, there is a plugin for that. Good luck. :)
I need to understand a fundamental concept about terminal multiplexers yet I can't seem to find the answer.
As I understand these programs need to be installed on server but not necessarily on clients. It's not a problem with gnu-screen as it is already installed on most systems but it's not the case for tmux and byobu. The problem is that I don't have permission to install software on the server. Is there a way I can run byobu from my client to show statistics about the server I connect?
Also what exactly is the effect of 'byobu-enable' option?
I think there is a misunderstanding here. When you connect to the server and run a command (byobu in this case), you are running the command on the server. Statistics reported are for the server. It's possible to open a byobu session on your own desktop of course, but if you're ssh'd into a machine, you're very likely to be executing commands on that machine.
byobu-enable sets byobu to launch automatically when you open a terminal. I don't do this since you can have confusion if you have byobu running locally and on the remote end you have connected to, which causes problems when you try to interact with byobu itself.