Due to fact that my VM is opening in small resolution I've been facing lots of situations with flaky tests, mainly about "Element is not clickable" notification. The solution to my problem might be adding extensions and increase the resolution:
https://marketplace.visualstudio.com/items?itemName=ms-autotest.screen-resolution-utility-task
The problem is I don't exactly know where it should be placed inside my pipeline which looks like this:
In order to run successfully this extensions there is a need to fulfill requirements:
Agent must be configured to run as an interactive process with autologin enabled (Where I should enable that?)
Shall I configure it directly by the "Demands" section on mine "Restart" agent options? I've tried putting the extensions inside the "Restart" section between "Stop" and "Start" agent tasks but it failed...
You can either reconfig your agent to interactive mode(check below detailed steps), or install a new agent and config it to interactive mode on your VM. Check here to install a new self hosted agent and check for more configuration.
1,
To reconfig your agent to interative mode, you need cd to the agent installation folder and run.\config remove to remove it first as shown in below pic.
2,
After agent is removed, Run .\config to reconfig your agent, and choose interactive during the configuration. Please refer to below screenshot and be careful to choose the right option (Y/N) at the highlighted steps
3,
To start the interactive agent by run .\run
Above steps should be ran as administrator. I followed above steps and successfully run set screen resolution task.
Related
Windows 10 has a new sandbox which is based on a very small and fast Hyper-V VM. With every start of the sandbox you get a "fresh" Windows and on every sandbox termination, all changes are discarded.
My question is: Is it possible to define in which state the sandbox starts? E.g. is it possible to start the VM with pre-installed reversing tools or a script that is automatically run, as soon as the system is booted?
Use case: Due to it's fast start-up time and "throw away" characteristics, the Windows 10 sandbox would be a dream for automated malware analysis.
You can somehow change the behavior of the sandbox. For example run a script at start up or disable network. See here for a how to: https://medium.com/#maarten.goet/how-windows-1903-makes-malware-analysis-easier-introducing-windows-sandbox-3ec791c8367
In general, sandbox startup can be controlled by a startup configuration file:
Windows Sandbox supports simple configuration files, which provide a
minimal set of customization parameters for Sandbox. ... Windows Sandbox
configuration files are formatted as XML and are associated with
Sandbox via the .wsb file extension.
The specific ability to execute a script upon sandbox startup is documented here: https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-configure-using-wsb-file#logon-command
It says:
Logon command
Specifies a single command that will be invoked automatically after
the sandbox logs on. Apps in the sandbox are run under the container
user account. The container user account should be an administrator
account.
XML
<LogonCommand>
<Command>command to be invoked</Command>
</LogonCommand>
Command: A path to an executable or script inside the container that
will be executed after signing in.
Note
Although very simple commands will work (such as launching an
executable or script), more complicated scenarios involving multiple
steps should be placed into a script file. This script file may be
mapped into the container via a shared folder, and then executed via
the LogonCommand directive.
I am currently using Chef's Jenkins supermarket cookbook to deploy an instance of Jenkins. As part of that deployment, my recipe includes installing Jenkins, installing specific plugin versions, enabling security and creating an Administrator account for Jenkins.
I'm currently using a single recipe file for this. The script that is executed to enable security and create the Administrator account is as follows:
jenkins_script 'activate global security' do
command <<-EOH.gsub(/^ {4}/, '')
import jenkins.model.*
import hudson.security.*
def instance = Jenkins.getInstance()
def hudsonRealm = new HudsonPrivateSecurityRealm(false)
hudsonRealm.createAccount("Administrator","administrator_passwd")
instance.setSecurityRealm(hudsonRealm)
instance.save()
def strategy = new GlobalMatrixAuthorizationStrategy()
strategy.add(Jenkins.ADMINISTER, "Administrator")
instance.setAuthorizationStrategy(strategy)
instance.save()
EOH
notifies :restart, 'runit_service[jenkins]', :immediately
end
The script activates security, creates the Jenkins Administrator user with a password, and then restarts the Jenkins instance. From what I understand, the jenkins_script resource executes Java or Groovy command against the Jenkins master, and is not idempotent.
As the script is not idempotent, if the recipe is run on the node subsequent times after the initial run, the chef-client run fails as security is already enabled and the Administrator user has already been created.
My thoughts are to move this security enablement script to its' own recipe file, and then specify the recipe for security in the node's run list if enabling security is required. If security has already been enabled, we simple don't add / remove the security recipe from the run list.
Is this a sound approach to working around this problem?
If this is a sound approach, should it be as simple as just
creating another ruby file, dumping the security code in it, and
adding it to the node's run list after the recipe for the initial
Jenkins install?
You don't have to restart Jenkins to configure security.
When configuring security there are a few considerations you have to take into account. One is that it almost always works the first run, but you want to make sure that on repeated runs it continues to successfully apply desired changes.
There is an attribute for the executor protocol which defaults to remoting and you'll see warnings all over about using it because it is less secure and has been deprecated. Other options are https or ssh, with the latter being the option we decided to go with. If you configure it as the protocol but the SSH key provided to be used isn't associated with a user (user has to be created and then an SSH public key associated with them) then it will fall back to using anonymous (part of the cookbook) and so you need to ensure you either do all your "privileged" operations like plugin installation and reconfiguration scripts before you enable authentication, or ensure you have the authentication pre-configured to request SSH so that it immediately kicks in when the authentication is turned on.
My goal is to create a Deployment Manager profile in my Websphere on Linux.
Reading tons of documentation pages gives just two methods:
1) using X GUI application WAS_root/bin/ProfileManagement/pmt.sh
In this case, according to manuals, i should choose Management option, click "Next" and choose Deployment Manager server type.
Actually when i run pmt.sh in my WAS installation there is no option to choose Deployment Manager in Management section and only one profile type that i'm able to create is AdminAgent.
2) using manageprofiles.sh script under WAS_root/bin directory.
The manuals say that i can use -serverType DEPLOYMENT_MANAGER option in order to create deployment manager profile.
Actually when i run the script:
./manageprofiles.sh -create -templatePath ../profileTemplates/management/ -ServerType DEPLOYMENT_MANAGER -isDefault -profileName dmgr -adminUserName websphere -adminPassword websphere1
I get the following message:
The following validation errors were present with the command line
arguments:
serverType: The value for this parameter must be within this set of values [ADMIN_AGENT]
That means that i don't have the ability to create Deployment Manager at all.
Please advise what steps i can perform to be able to install Deploy Manager except erase my WAS installation and install it from scratch once again.
Thanks a lot.
You have standalone aka base edition of WebSphere Application Server. To create Deployment Manager you need Network Deployment edition.
Unfortunately you will have to install it from scratch from different installation files (from ND, not base or developers edition).
I am currently trying to automate the process of bamboo remote agent installation and uninstallation. I have run into a problem in regards to adding and removing capabilities.
What I am trying to automate:
(The following is what I do on the bamboo server via the GUI, I want to do this on the remote agent machine via bash script.)
I install the remote agent on a VM machine, then start it up. I go to the bamboo interface and click on the newly created agent's name.
I add a custom capability type, for the key I put 'buildserver' and for the value I put the name of the agent.
I add an 'Executable' capability of type 'Command' with Executable label 'cygwin' and path 'C:\cygwin64\bin\bash'
I navigate to the git executable, and remove it by clicking 'delete.' <--- (the problem step)
what I've done.
I have looked here and found a way to automate steps 1-3 using the following "bamboo-capabilities.properties" file:
buildserver="AGENTNAME"
system.builder.command.cygwin="C:\cygwin64\bin\bash"
However I am stuck on how I would remove the git capability (step 4.) I've tried something appending something like this to the file:
system.git.executable=""
but it does not seem to do anything. Does anyone know how I would do this? There seems to be very little documentation about this online.
Thanks very much.
I never found a way to get around this, but I found a workaround. I later learned the point of removing git in my situation was to allow a shared capability that was also called git to take precedence. My workaround was to set the non-shared capability to the value of the shared capability. I am not 100% sure that this does the same thing, and I am not in a position to test it yet, but as a capability seems to be only a key-value pair I don't see why it wouldn't.... will update if anything breaks.
I have a Redhat 5 OS, a dual monitor setup, and two workspace. When the machine reboots, I want to set the following:
On workspace 1,
* run the thunderbird-client on the left monitor.
* run 3 terminal clients on the right monitor.
On workspace 2,
* run firefox on the right monitor.
Can someone point me as to where I can set these settings? I am sure there is a way since when my machine boots up, couple of terminal clients pops up, my irc chat client pops up as well. I do not know how I did this before.
You could try Devil's Pie (yum install devilspie)
It's a tool for creating rules that will bind specific actions to applications as they are launched (i.e. setting workspace, position, transparency, etc...).
I found some doc here: http://www.foosel.org/linux/devilspie and here: http://live.gnome.org/DevilsPie
Of course, saving your workspace on logout can help too (System > Preferences > More Preferences > Sessions, then check "Automatically save changes to session").
Once you have setup your application rules, you could write a simple Bash script to start them all in sequence, and add that script to the Startup programs in the sessions preferences.