My goal is to have the com0com serial driver install without popping up the install wizard on both WinXP and Win2000.
I am working on WinXP x86. I have followed the test signing instructions for the com0com driver, replacing amd64 with i386 at line 60.
I have added my test certificate as both a root and trustedprovider using the following commands:
certmgr /add com0com.cer /r localMachine root
certmgr /add com0com.cer /r localMachine trustedprovider
And verified that it is listed under both locations.
I then run the newly built setup.exe. This installs the signed com0com.sys file into C:\WINDOWS\system32\DRIVERS and sets up a pair of virtual serial ports and a bus between them. Using explorer, I go to the DRIVERS directory, right click on the com0com.sys file and verify that it has the "test" digital signature. I then go into Device Manager, open the "com0com serial port emulators" entry, pick an entry and do Properties->Driver and see that it says "Not digitally signed". I click details for the driver and can see that it is referring to the com0com.sys driver file that I just confirmed is signed.
I found what might be a related issue but I'm not sure. Does WinXP demand a WHQL signature? If so, does that explain why the com0com.sys file is signed but the device driver entries say they aren't signed?
Yes, when talking about drivers, Windows 2000 and Windows XP has only one certain signature in mind -- the WHQL signature. Without putting the com0com driver through the WHQL process, it simply won't be considered signed.
The instructions in Building.txt in relation to signing are talking about a different "constraint" placed by 64-bit editions of Windows Vista and higher -- they simply won't load drivers which are not signed at all -- but that's unrelated to your problem.
Related
I am building kernel and ramdisk image for ARM target using buildroot. I want to provide a certificate for the ARM target, which requires me to create a cert request from within the ARM target (I guess using fakechroot, and openssl from within chroot environment). Should I be able to do this (possibly from a postscript) ? I see buildroot generates out/build/host-fakeroot-$(version) folder, where there is a faked, there is also fakechroot installed thru a debian package on my system (ubuntu). But I am clueless as to what command needs to be used to generate the request from within chroot, run purely host-side commands to generate the cert, and then concatenate and put the cert back into target, this requires me to go in and out of chroot if i will be doing everything from a postscript.
Thanks
Ratin
I'm trying to install a newer version of Eclipse. The Oomph Eclipse installer keeps giving me the following error:
I'm definitely connected to the network - and I've done everything I can think of with Configure Network Proxy Settings. I still get the error every time.
Any suggestions?
Thanks!
I experienced something similar today. For me, it related to my company's internet making use of a security tool called Netskope that intercepts https traffic (yep, companies are sniffing our private traffic too now ;)).
I've experienced similar network issues with other tools at work (like python pip installer), and our IT dept advised that we need to install a Netskope root certificate into any tool we use that doesn't make use of the operating system's security store (and they use their own).
So, to get a feel for how this issue impacted me in relation to this "eclipse-inst-jre-win64.exe" installer file, I learnt that I could run the installer with an extra argument, to specify my own jvm:
eclipse-inst-jre-win64.exe -vm "C:\Program Files\Java\jre1.8.0_251\"
This got me the following error:
...and that was the clue I needed to realise that this Eclipse installer .exe had JDK 11 built into it.
So, given that, I felt that I should try download my own JDK 11 and add this 'netskope.pem' root certificate into that, so I'll share my steps in doing so:
I grabbed jdk-11 from here:
http://jdk.java.net/java-se-ri/11
I extracted the “openjdk-11+28_windows-x64_bin.zip” file onto my local drive
E.g. to “C:\Users\GurceI\Downloads\jdk-11\”
Added ‘nscacert.pem’ to jdk-11’s keystore from the command-line, with:
cd c:\Users\GurceI\Downloads\jdk-11\
bin\keytool.exe -import -keystore lib\security\cacerts -file c:\ProgramData\netskope\stagent\download\nscacert.pem
(default keystore password = “changeit”)
I then ran the eclipse-installer with an extra argument to point it to my jdk-11 (rather than its internal one):
eclipse-inst-jre-win64.exe -vm "C:\Users\GurceI\Downloads\jdk-11\"
...and then, finally, the installer worked, no more network issues :)
I got the same error with "The catalog could not be loaded. Please ensure that you have network access... on my Windows 10 laptop.
I know the installer works since I was able to install Eclipse on another system. I went to eclipse.org, then to More, Eclipse IDE Download, then choose
"Get Eclipse", then click on Download Packages. Choose your OS. In my case, I chose Eclipse IDE for Java Developers, Windows x86_64. This will start downloading the eclipse install .zip file.
Once unzipped, I was able to install by launching the .exe.
Hope this helps.
change "native" to "manual" and then you configurate your http and https proxy parameters, it works to me! (Windows)
The issue here is eclipse installer is using its own jdk for installation which is present under eclipse-inst.ini . The installation details can be found after -vm line.
If your organisation mandated to use their own root certificate then you have to first add root certificate's entry into your JDK & then modify eclipse-inst.ini to point to your installed JDK.
So to fix this issue, you can either refer #Gurce's great answer or you can do following: :
Download certificate & add root entry to following (Mac command) :
sudo keytool -importcert -file "/Users/<User Account Folder Name>/Documents/cert.pem" -alias anyalias -keystore "/Library/Java/JavaVirtualMachines/<JAVA Version Folder Name>/Contents/Home/jre/lib/security/cacerts" -storepass changeit
Once added you can verify if entries gets added or not by using following command:
keytool -list -v -keystore cacerts
After this, download eclipse installer & find eclipse-inst.ini file.
Open that file in text editor mode & find line which is present after -vm
Remove that jdk version & use your own installed jdk which has your organisation's root cert. So modified ini file will look like , (other file details omitted) :
...
-vm
/Library/Java/JavaVirtualMachines/jdk-17.0.2.jdk
-vmargs
..
If its not required to add root certificate into JDKs cacerts, then you can directly follow point 3 , use your own installed JDK in ini file & see if it works.
I was on linux mint, so I clicked on change the proxy settings and only changed to manual and it worked.
Here I treid everything but at the end this error can be sorted by
uninstall the java JRE
Uninstall the java JDK
Then again install the eclipse
After that you can again install java JDK and JRE
Struggling to notarize DMG created with install4j v8.0.8. This is what I do:
the install4j runs on Windows machine
we use "MacOS folder archive" media packaged into DMG
everything is signed as required with valid "Developer ID Application" certificate
the DMG then taken to MacOS machine (Big Sur) where we do notarization with our own scripts
notarization fails with an error "The signature of the binary is invalid" pointing to one specific file
When I check the signature of that binary with Mac tools it looks perfectly fine. When I check the signature of the DMG, it looks fine too:
$ codesign -vd --verbose=4 path-to-failed-binary
$ codesign -vvv --deep --display path-to.dmg
When I remove this particular binary from the package, the app gets notarized fine (there are many other binaries inside the package, like JRE). Looking around I see similar problems related to the way the package is zipped.
Which makes me wander if it even possible to create DMG on Windows machines with install4j and then doing the manual notarization on Mac? Or, there is something wrong in install4j creating the DMG package?
I'm on a Windows 7 (64-bit) box and do not have admin rights.
It appears from the MongoDB download page (see http://docs.mongodb.org/manual/tutorial/install-mongodb-on-windows/) that the latest version only an MSI install is available (no zip version).
I tried running the 3.0.4 MSI. I clicked custom so I could change the directory to install to. I used %USERPROFILE%\MyProgs\MongoDB-3.0.4, so no admin rights would be needed. It ran for a bit but then prompted me to enter admin credentials. I hit escape (like clicking on X at top right) to close the window. On other MSI installs this has worked. I tried it again and clicked "No" but in both cases received the message
MongoDB 3.0.4 2008R2Plus SSL (64 bit) setup was interrupted.
Your system has not been modified. [...]
This article does a GREAT job going through how to install MongoDB on Windows:
How to install mongoDB on windows?
My observation is that v2.4.14 is the last version that is available via the ZIP format. So for now, I'm using that version.
Is there any other way to install the MongoDB version 3.X MSI without admin rights?
NOTE: On the MongoDB Download page https://www.mongodb.org/downloads there is a link titled View Build Archive (it sends you here https://www.mongodb.org/dl/win32/x86_64-2008plus-ssl, and that site lists *.zip formatted files). I thought I had found my own solution to the question, but when I unzipped the files, and added the "bin" to my path and ran the programs (mongo, and mongod) I received an Windows Dialog that says:
mongod.exe - System Error
The program can't start because LIBEAY32.dll is missing from your
computer. Try reinstalling the program to fix the problem
I stopped here and posted this question. Thanks for any help.
For now I'm using the version that supported the zip format (v2.4.14) and that version does work.
NOTE2: The v2.4.14 zip formatted install doesn't have a file named LIBEAY32.dll), or I might have tried using that file with the newer version.
Yes, it is possible to install the latest MSI (including the one with SSL) without admin rights via command line.
msiexec /a mongodb-win32-x64-3.2.5.msi /qb TARGETDIR="C:\MongoDB"
This will copy the binaries into C:\MongoDB\MongoDB\Server\3.2\bin
I dislike long paths like that, so I create a symlink inside the folder:
cd C:\MongoDB
mklink /j bin C:\MongoDB\MongoDB\Server\3.2\bin
That will create a soft link as C:\MongoDB\bin (which you can add to your PATH environment variable).
mongo --version
mongod --version
Both should return version 3.2.5.
You can do this with most packages, we have to do similar with Python 2.7 and Node 4.4.3 MSI packages on work computers that do not have admin rights.
You can download the "legacy" version which is the unsigned non msi version as a zip. The disclaimer is listed as
The 64-bit legacy build does not include SSL encryption and lacks
newer features of Windows that enhance performance. Use this build for
Windows Server 2003, 2008, or Windows Vista
The 3.0.5 version is https://fastdl.mongodb.org/win32/mongodb-win32-x86_64-3.0.5.zip
The latest version is available as zip download.
[https://www.mongodb.com/dr/fastdl.mongodb.org/win32/mongodb-win32-x86_64-2008plus-ssl-4.0.6.zip/download][1]
Download and Unzip into folder where user has permissions e.g c:\users\xxx\mongodb.
Enter the path to bin folder (e..g c:\users\xxx\mongodb\bin) into the
environment variable 'PATH'. To access path variable press Win + R
and then enter rundll32 sysdm.cpl,EditEnvironmentVariables.
Select Path and click edit. Then enter new and there enter the path
to bin folder. Click OK and OK to save and exit.
Check Mongo version from command line using command mongo --version.
Note: Don't forget to create db folder in C drive that is required for mongo to work locally. All set.
I'm trying to deploy an application on Windows Server 2008 (SP2 x64) and Windows 7 (x64), using VS2005 Installer Project. The MSI version (I think) it the 2.0.
Everything works fine, except that some registry keys and some files are not copied on the install machine. The MSI system doesn't notify about nothing (and I don't know whether MSI logs its operations).
Are there incompatibilities between my MSI installer project and these new OSes? It seems to me that the OS protect itself for being modified in some part.
For example, I'm trying to set the registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\WinLogon\SpecialAccounts\UserList\User
but it is not created. In the same installer there are many other keys, which are created like expected (as they always did before on Windows XP and Windows Server 2003).
To provide another example, I'm trying to install the file
%SystemFolder%\oobe\info\backgrounds\backgroundDefault.jpg
(where %SystemFolder% is typically "C:\Windows\System32"), but the file is not copied at all!!!
What's going on?
I've found the backgroundDefault.jpg file is located in another directory: %SystemRoot%\SysWOW64\oobe\info.
But I've not specified nothing about a System (64 bit) folder. How can I copy the file in the right place?
First, regarding logging, you can request MSI to create a log file of its operations like this:
msiexec.exe -i my_msi_file.msi -l*vx logfile.txt
This will create a log file called logfile.txt.
Second, it sounds like you're creating a 32-bit MSI and running it in 64-bit Windows. There is nothing wrong with this, but be aware that Windows is using file system redirection. Windows has a separate SystemFolder and HKLM/SOFTWARE keys to host 32-bit applications. If you look in the Registry at HKLM/SOFTWARE you'll probably see a sub-key called Wow6432Node -- this is where 32-bit apps write their Registry data.