I am writing a shell script that will read OpenDJ installation properties from a file and install OpenDJ.
I have read their documentation and prepared the properties file with required data.
hostname=punvm-core06.sigmasys.net
ldapPort=1389
generateSelfSignedCertficiate=true
#no-prompt=true
#enableStartTLS = true
#ldapsPort = 1636
jmxPort=1689
adminConnectorPort=4444
rootUserDN=cn=Directory Manager
rootUserPassword=ldappass
baseDN=dc=myldap
skipPortCheck=true
doNotStart=true
#usePkcs11Keystore = true
#keyStorePassword = password
When I run command from opendj unzipped setup it prompts me for license agreement to accpet even after putting --no-promt option i.e -n .
./setup -n -i --propertiesFilePath openDJ.properties
Due to this my installation does not proceed. What am i missing here.
I got the answer , there is paramter called --acceptLicense that can be passed. Thier use manual is bit unreadable form i missed it.
If documentation is unclear, you should create a ticket for improvement on the OpenDJ project issue tracking system
Related
There is Prometheus Oracle database exporter https://github.com/iamseth/oracledb_exporter
Under Running section, "/path/to/binary -l log.level error -l web.listen-address 9161" is not clear me.
Here I am not getting what is "/path/to/binary" mean, is it oracle client or /usr/bin/ path, or which file I need to replace with? I have RHEL7.3
After setting DATA_SOURCE_NAME is set correctly and running below commman, its throwing error (no such cmd - /path/to/binary)
/path/to/binary -l log.level error -l web.listen-address 9161
Please refer ZIP/clone from location :-https://github.com/iamseth/oracledb_exporter
Oracle database exporter should start and fetch required values/status from oracle database.
In case you're still looking for the answer:
The easiest way is to download the pre-compiled version. Otherwise you will need to compile it yourself: https://github.com/iamseth/oracledb_exporter/releases
Download the version you want e.g. 'oracledb_exporter.0.2.2.linux-amd64.tar.gz' and unzip it.
You will get a folder 'oracledb_exporter.0.2.2.linux-amd64' which conatins two files:
default-metrics.toml
oracledb_exporter
The second one is the one you need to execute:
-> /path_to/oracledb_exporter.0.2.2.linux-amd64/oracledb_exporter log.level error web.listen-address 9161
I have a bunch of unit tests which contain code like:
File file = new File("src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
This test is suddenly failing when running it with Maven Surefire and -DforkCount=0. With -DforkCount=1, it works.
Things I tried so far:
The file does exist. Windows Explorer, command line (copy & paste), text editors, Cygwin can all find it and show the contents. That's why I think it's not a permission problem.
It's not modified by the unit tests or anything else. Git shows no modifications for the last two months.
I've checked the file system, it's clean.
I've tried other versions of Java 8, namely 8u171 and 8u181. Same problem.
I've run Maven from within Cygwin and the command prompt. Same result.
Reboot :-) No effect :-(
More details:
When I see this problem, I start to see the "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" in other projects. That's why I tried forkCount=0 which often helps in this case to find out why the forked VM crashed.
This has started recently, maybe around the October 2018 update of Windows 10. Before that, the builds were rock solid for about three years. My machine was switched to Windows 10 late 2017, I think.
I'm using Maven 3.6 and can't easily try an older version because of an important bug that was fixed with it. I did see the VM crash above with Maven 3.5.2 as well.
It's always the same files which fail (so it's stable).
ulimit (from Cygwin) says:
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 2032
cpu time (seconds, -t) unlimited
max user processes (-u) 256
virtual memory (kbytes, -v) unlimited
I'm wondering if the "open files" limit of 256 only applied to Cygwin processes or whether that's something which Cygwin reads from Windows.
Let me know if you need anything else. I'm running out of ideas what I could try.
Update 1
Bernhard asked me to print absolute names. My answer was that I was already using absolute names but I was wrong. The actual code was:
File file = new File("src/main/java/com/pany/Foo.java");
if (!file.exists()) {
log.debug("Missing file {}", file.getAbsolutePath());
... fail ...
}
... do something with file...
I have now changed this to:
File file = new File("src/main/java/com/pany/Foo.java").getAbsoluteFile();
if (!file.exists()) {
log.debug("Missing file {}", file);
}
and that fixed the problem. I just can't understand why.
When Maven creates a forked VM to run the tests with Surefire, then it can change the current directory. So in this case, it would make sense that the tests work when forked but fail when running in the same VM (since the VM was created in the root folder of the multi-module build). But why is making the path absolute before the call to exists() fixing the issue?
Some background. Each process has a notion of "current directory". When started from the command line, then it's the directory in which the command was executed. When started from the UI, it's usually the folder in which the program (the .exe file) is.
In the command prompt or BASH, you can change this folder with cd for the process which runs the command prompt.
When Maven builds a multi-module project, it has to change this for each module (so that the relative path src/main/java/ always points to the right place). Unfortunately, Java doesn't have a "set current directory" method anywhere. You can only specify one when creating a new process and you can modify the system property user.dir.
That's why new File("a").exists() and new File("a").getAbsoluteFile().exists() work differently.
The latter will use new File(System.getProperty("user.dir"), "a") to determine the path and the former will use the Windows API function _wgetdcwd (docs) which in turn uses a field of the Windows process to get the current directory - in our case, that's always the folder in which Maven was originally started because Java doesn't update the field in the process when someone changes user.dir and Maven can only change this property to "simulate" changing folders.
WinNTFileSystem_md.c calls fileToNTPath(). That's defined in io_util_md.c and calls pathToNTPath(). For relative paths, it will call currentDirLength() which calls currentDir() which calls _wgetdcwd().
See also:
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/WinNTFileSystem_md.c
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/io_util_md.c
and here is the place where the Surefire plugin modifies the Property user.dir: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1060
When not forking, it's copied into the current VM's System properties: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1133
So I have checked via printing out the system properties with some simple tests.
During the tests via maven-surefire-plugin the user.dir will be changed to the root of the appropriate module in a multi module build.
But as I mentioned already there is a system property available basedir which can be used to correctly handle the location for tests which needs to access them via File...The basedir is pointed to the location of the pom.xml of the appropriate module.
But unfortunately the basedir property is not set by IDEA IntelliJ during the test run.
But this can be solved by a setup like this:
private String basedir;
#Before
public void before() {
this.basedir = System.getProperty("basedir", System.getProperty("user.dir", "Need to think about the default value"));
}
#Test
public void testX() {
File file = new File(this.basedir, "src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
}
This will work in Maven Surefire with -DforkCount=0 as well as -DforkCount=1 and in IDE's (checked only IDEA IntelliJ).
And yes that is an issue in Maven Surefire plugin changing the user.dir.
We might convince IDE's to support the basedir property as well ?
Aaron, we develop the Surefire. We can help you if you provide the path for this:
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
Pls post the actual path, expected path and basedir where your POM resides.
The theory would not help here. We are testing all the spectrum of JDKs 7-12 but we do not have the combination Cygwin+Windows which must be considered.
The code setting user.dir in Surefire you mentioned exists a decade.
My Intent
I have an image generated by BitBake on which I'm interested in changing the window manager to metacity or maybe something similar.
My Process
I've added require recipes-graphics/images/core-image-x11.bb into my core recipe, which provides a simple Matchbox terminal window but seemingly no other functionality. If I add matchbox-desktop and matchbox-session-sato, it adds a bit more usability but not what I'm looking for.
I've included the default package from the metacity_2.34.13.bb recipe from the meta-gnome layer from the OpenEmbedded Metadata Index in the IMAGE_INSTALL variable of my core image. This installs several components including a metacity command in /usr/bin. If I run that command, I get the following message:
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications
(metacity:1124): GLib-GIO-ERROR **: Settings schema 'org.gnome.metacity' is not installed
Trace/breakpoint trap
I've navigated to /usr/share/glib-2.0/schemas and run glib-compile-schemas ., then run:
startx
metacity --replace
again. Now, the output is:
Window manager error: Unable to open X display
I haven't found a clear solution to this error which applies to my specific situation.
Update (2/29):
I may have now found a solution to this error, using these commands:
X&
export DISPLAY=:0
metacity&
At this point, I seem to be running something on one of my VTs. I can run demos like glxgears in that VT (glxgears is included in the mesa-demos recipe), but I don't know how to actually create a usable environment.
My question(s)
I'm not using much from meta-openembedded/meta-gnome (just metacity) or meta/recipes-gnome (adwaita-icon-theme, gnome-desktop3, gsettings-desktop-schemas and gtk+3), so am I missing some recipe which automates the addition of metacity?
(if not Question 1) How can I solve the error Window manager error: Unable to open X display?
The x11-common recipe adds a X session script that will run /usr/bin/x-session-manager: that is responsible for starting your desktop environment.
The way to implement a new session/DE in OE-Core is to use update-alternatives for "x-session-manager": see the matchbox-session recipe for the default implementation and mini-x-session recipe for an alternative.
mini-x-session might be modifiable for your needs so you don't need to write a new one: A /etc/mini_x/session file like this might do the trick:
# start any apps here, e.g. "my-desktop &"
exec metacity
Going from this (a running window manager) to "usable environment" might still be lots and lots of work, depending on your definition of usable.
I'm trying to replicate the following Chocolatey command line install in Puppet:
choco install visualstudio2013ultimate -InstallArguments "/Features:'WebTools SQL OfficeDeveloperTools LightSwitch'"
I've referred to the documentation on using quotes in install arguments and have tried:
package { 'visualstudio2013ultimate':
ensure => '12.0.21005.20141031',
install_options => ['-installArgs','"','/Features:', '""','WebTools SQL OfficeDeveloperTools LightSwitch','"""','"'],
}
But this is failing to have the desired effect (it installs Visual Studio, then treats WebTools, SQL etc. as additional Chocolatey packages to install, not arguments to the Features switch).
Chocolatey log snippets:
2016-02-24 12:15:46,704 [DEBUG] - Command line: "C:\ProgramData\chocolatey\choco.exe" upgrade visualstudio2013ultimate -version 12.0.21005.20141031 -dvy -installArgs " /Features: "" "\"WebTools SQL OfficeDeveloperTools LightSwitch\"" """ "
2016-02-24 12:15:46,719 [DEBUG] - Received arguments: upgrade visualstudio2013ultimate -version 12.0.21005.20141031 -dvy -installArgs
/Features: " "WebTools SQL OfficeDeveloperTools LightSwitch" "
Version='12.0.21005.20141031'|AllVersions='False'|
SkipPackageInstallProvider='False'|
PackageNames='visualstudio2013ultimate;SQL;OfficeDeveloperTools;LightSwitch" ";'|
Can anyone advise how to correctly format the install_options?
The documentation for install options with the provider is very clear: every space must be covered with a separation. Puppet will automatically put quotes around a section with spaces, messing up the arguments. Splitting statements on every space keeps the spaces when Puppet reconstructs the arguments and keeps Puppet from messing with the resulting value passed to Chocolatey.
I also noticed that your documentation link points to a Github issue, not the resulting documentation. I realize the issue was the one about adding the documentation, but it wasn't quite correct in the issue notes. So it's probably better to refer to the resulting documentation that is most up to date. See https://forge.puppetlabs.com/chocolatey/chocolatey#install-options-with-spaces
I can't get windows 8 (release preview) to accept either the inf2cat or makecat approach described as solutions to the question at
What changed in the driver signature requirements for Windows 8?
unless I disable validation.
I am not signing these with any certificates at this point, just trying to get past the errors preventing the drivers from installing at all.
Windows 8 gives me a very nondescript error:
"A problem was encountered while attempting to add the driver to the store."
Looking in the event logs, there is nothing of use; only an informational entry from "Windows Error Reporting" indicating a PnPdriverimporterror.
When i use my original files with the cab files that don't match the inf, I get the error everyone else is listing:
The hash for the file is not present in the specified catalog file.
I have one .inf file that i need to generate a .cat for.
Perhaps I am doing something wrong. Ideas??
INF2CAT Approach
c:\win_xp_vista32_64>inf2cat /driver:"." /os:XP_X86,XP_x64,Vista_X86,Vista_x64,7_X86,7_X64,8_X86,8_X64
.......................
Signability test complete.
Errors:
None
Warnings:
22.9.10: usbser.sys in [drivercopyfiles.nt] is missing from [SourceDisksFiles] s
ection in \mchpcdc.inf; ok if file source is provided via LayoutFile in [Version
].
22.9.10: %driverfilename%.sys in [drivercopyfiles.ntamd64] is missing from [Sour
ceDisksFiles] section in \mchpcdc.inf; ok if file source is provided via LayoutF
ile in [Version].
Catalog generation complete.
c:\win_xp_vista32_64\mchpcdc.cat
MAKECAT approach
--- start of catalog.cdf file---
[CatalogHeader]
Name=mchpcdc.cat
ResultDir=.\
[CatalogFiles]
<hash>mchpcdc=.\mchpcdc.inf
---end of .cdf file ---
c:\win_xp_vista32_64>makecat catalog.cdf
These same files, w/ the cat from either approach install just fine in Windows 7.
I think this problem is to do with "windows driver signing enforcement". You can resolve this by disabling this option. Go through with below link:
http://tivadj-tech.blogspot.in/2012/09/certificate-check-error-when-installing.html
I just tested this on Windows 10 and 8 PRO now, to get this right, follow these steps:
1) From your Start menu, locate your DDK's "x64 Checked Build Environment" i.e. the custom DOS build screen. Right-click, run-as administrator...
2) Compile your source with the Build tools etc.
3) Go into your compiled code, and then create your test-certificate (you don't need to purchase one just yet, use your self-signed one created with the line below):
makecert -r -pe -ss PrivateCertStore -n CN=newhex.com(Test) NewhexTest.cer
The above means your certificate is called "newhex.com(Test)" and the generated file is "NewhexTest.cer"
4) Create / Edit your .CDF file which contains items about what your CAT file's contents.
5) Create your CAT file by executing:
makecat -v MyCDF.CDF
This should generate an un-signed CAT file that includes all files specified by your CDF.
6) Sign your CAT file as follows:
Signtool sign /v /s PrivateCertStore /n newhex.com(test) /t http://timestamp.verisign.com/scripts/timestamp.dll MyDriverWhatever.cat
This should result in a CAT file that is signed, but don't just install it, because your Windows can't trust Newhex's cert since it's not in the keystore, to fix this do:
7) Add your certificate to your private Key Store, remember this step MUST be done by an administrators access, otherwise you will get an error about (Keystore not found etc):
certmgr.exe -add NewhexTest.cer -s -r localMachine root
This should add into your keystore, Once done, you can then:
8) Go into your device manager, and add your new driver, you would get a warning but will be accepted and installed without the need to reboot with a forced (Don't check cert type account).
I tried this already and it works on Windows 10 and Windows 8 pro versions.
Kind Regards
Heider Sati
You are supposed to use inf2cat, not makecat, because you have an INF file.
You should work on addressing those warnings from inf2cat by fixing your INF file. Here is my INF file that uses usbser.sys and doesn't cause any warnings: https://gist.github.com/3647208
I was able to fix my INF file thanks to the advice from chinzei in the first post of this thread: http://www.microchip.com/forums/m488342-print.aspx
If you continue to have trouble, please edit your question to include the source of your INF file, or at least a link to the source.
I encounter the same problem and was able to install my driver with a TEST certificate using the instructions provided here:
http://msdn.microsoft.com/en-us/windows/hardware/gg487328.aspx