When I run:
openssl genrsa -out mykey.key 2048
I get the following error:
unable to write 'random state'
e is 65537 (0x10001)
My googling suggests this is some kind of Vista permissions issue. How can I allow Vista to write this file or how can I configure openssl to get round it?
The root issue is that the RANDFILE variable in the OpenSSL configuration file is ignored on Windows. This has been a long-standing problem that continues to exist as of the OpenSSL v1.0a release, regardless of whether the target Windows platform is x86 or x64.
There is a delightfully simple solution, though. Merely use a regular environmental var to set the RANDFILE value, like
set RANDFILE=.rnd
Because this value is ephemeral, it must be re-issued for every new DOS box, or scripted in a batch file.
I found this that might help: Using OpenSSL what does "unable to write 'random state'" mean?
also, here: http://adamyoung.net/OpenSSL-unable-to-write-random-state
there is a suggestion here http://www.mail-archive.com/openssl-users#openssl.org/msg51344.html on how to get it working in vista.
find the location of cmd.exe, right click and run as administrator
I had the same issue but for Windows 7. Easily solved, I created a system Environment Variable called HOME and set it to the directory I wanted my .rnd file in. This solved the issue because OpenSSL didn't know where my .rnd file was (because I didn't have one) and it didn't know where to put it if it was to create it. As soon as I set my environment variable HOME with a directory (c:\ is fine!) I reran my key generation in OpenSSL and it worked straight off. To verify, I checked the key I had created and it had proper content. I also checked the directory I set my HOME environment variable to, and lo and behold a .rnd file was sat there! Hope this helps someone :-)
Add a HOME variable into your environment variables.
The issue is that the script is missing some access rights or cant find the file.
The solution:
Create a system variable with the name RANDFILE and the value %USERPROFILE%.rnd
Notice the %USERPROFILE%, is a system variable that automatic inserts the path to your user profile.
Related
I would require some guidance in regards to installing a module/package in pycharm (free edition). I have to mention that i have not worked with this IDE yet and wanted to try it out on a little project containing smartcards.
When i try to install "pyscard" i get the error that boils down to
error: command 'swig.exe' failed: No such file or directory
People say just install SWIG, which i guessed already ^^.
The issue i have is that i actually have no idea how to... and none of the pages i found has really enlightended me on this issue.
I downloaded the zip "swigwin-3.0.12" but i am at a loss what to do with it now. EDIT: According to the SWIG page this is an already compiled version and i have to somehow make pycharm recognize that the folder it is in contains the swig.exe it requires.
EDIT2: Adding the folder containing the swig.exe to the PATH variable also did not work ... which i thought would be the issue
EDIT3+Answer:
Ok the link in the comments from "wp78de" was correct my problem was that pycharm/pc restart were needed for it to catch the added PATH variable to the swig.exe (for pycharm that is)
Any advice is appriciated.
Envoirment:
Windows 8.1 Pro 64-bit
Pycharm 2017.2.4
Python 3.6
Basically, you just have to add the directory that contains the swig executable the PATH environment variable. You can do it via CMD or the Windows UI.
If you have added swig to your path, you should be able to call it in the command prompt from any directory: open "cmd", and type swig --help" on that prompt.
A restart of PyCharm (or whatever your IDE is) and Windows might be required.
I am trying to get some code running which uses make. I've downloaded and installed both MinGW (standard 32 bit) and TDM-GCCs flavor of MinGW on my 64-bit Windows 7 machine.
When I run make (i.e. mingw32-make.exe) in Administrator mode, I get the following error message:
Windows cannot access the specified path, or file. You may not have the appropriate permissions to access the item.
The weird/scary part is that, upon running, it immediately deletes the exe file.
I ran a checksum SHA1 as recommended in the comments using the Microsoft (R) File Checksum Integrity Verifier V2.05:
C:\path\to\folder>fciv.exe -sha1 mingw32-make.exe
//
// File Checksum Integrity Verifier version 2.05.
//
c8ae5c780ab7bed652883d6443b5bfe5e23d30c9 mingw32-make.exe
I don't understand what this output means, but maybe it's helpful to someone.
Notes:
This happens regardless of where the file is located on my pc.
This behavior is specific to the make program (others such as gfortran and gcc appear to be working fine)
Renaming the file makes no difference.
I am an administrator on the pc
Same behavior when I run the program from the explorer or command line.
My anti-virus program (Avast) does not detect any problems with the file when I scan it.
I got the MinGW setup file from this SourceForge page.
I got the TDM-GCC web installer from this page.
The file size is 219,662 bytes (from both the main MinGW and TDM-GCC packages)
I have run make from the command line where I have started the command prompt by way of selecting Run as Administrator in the context menu.
I have also tried to run make by selecting Run as Administrator when I have it selected.
I run the command mingw32-make when this behavior occurs. I have also tried renaming it to things like make and foo with the same result.
The first time this happened with both MinGW it deleted the original file and I re-installed it using the mingw-get application. From thereon after I started making copies of the original mingw32-make for testing.
For the make executable, I have all permissions (including Read & execute) except the special permissions field.
After using the process manager I found out it was indeed Avast that was the problem :S A couple of lines revealed avast actually deleted the file before windows got around to executing it, which was the reason for the windows message. I put Avast on 'Silent Mode' a while back; I thought the only purpose of this mode was to suppress notifications about minor updates, but apparently it also gave Avast permission to deal with 'threats' silently as well.
After figuring that out the solution was straightforward. I just went into the settings and created an exception for the mingw32-make.exe file. It now runs without issue.
Thanks very much for your help everyone!
User account has administrator privilege but when user started to work , not all privilege are taken in account , just start your application for compiling with run with administrator mode try this : https://technet.microsoft.com/en-in/library/cc781763(v=ws.10).aspx
THis is a quite basic question, and I am not sure why i haven't been able to solve it.
Essentially in this guide
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https.html
I am trying to get pass by the following step:
Enter the path to the OpenSSL installation:
c:\ set OpenSSL_HOME=path_to_your_OpenSSL_installation
In particular, path_to_your_OpenSSL_installation
When I downloaded and install openssl the folder it is found
c>OpenSSL and all its files is found inside that folder, I am not sure how to configure that path.
Another question I have is whats the point of geotrust, or verisign if you can use openssl as https for free.
Type set prog in command line window to see how similar paths look like:
d:\bat>set prog
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
d:\bat>
So you could type either
set "OpenSSL_HOME=%ProgramFiles%\OpenSSL" if you run 64-bit Windows and have downloaded 64-bit OpenSSL version, or
set "OpenSSL_HOME=%ProgramFiles(x86)%\OpenSSL" in case of 32-bit version of windows or OpenSSL
Note an error in your guide To include OpenSSL in your path; should be as follows:
set "Path=%OpenSSL_HOME%\bin;%Path%"
However, change your PATH system environment variable no sooner than the OpenSSL_HOME variable exists and %OpenSSL_HOME%\bin points to an existing directory.
Read about set (changes made to the environment variables are valid only for the current command-line session) versus setx (set environment variables permanently).
I installed Python 2.7.3 on my Windows 7 computer using the binary, the first link. After installing it, IDLE works but nothing else recognizes Python. For example, typing python at the command prompt returns the message "'Python is not recognized as an internal or external command, operable program or bath file."
Following this post, I made sure that python 2.7 was in the PYTHONPATH environment variable. However, that didn't help.
What should I do?
PYTHONPATH system variable is used by Python itself to find directories with installed packages.
PATH system variable is used by OS (particularly Windows) to find executables which can open certain files like *.py scripts.
So, you need to add directory with python.exe (for example C:\Python27) to PATH system (or user) variable and not to PYTHONPATH. It can be done the same way as described in the link you've found in the same tool window.
For example on my machine PATH system variable is set to C:\Python27;C:\MinGW\bin;...
Like Vladimir commented, for setting up python in windows, you need to add the directory where your python.exe is located (for example C:\Python27) to PATH
You can confirm if python is in your environment variables by looking at the output of echo %path%
Keep in mind that after editing the PATH variable using the control panel, you have to open a new terminal, as the setting will NOT be updated in existing terminals.
Another possibility is that you added the wrong path to the PATH variable. Verify it.
The bottom line is, if the directory of your python.exe is really in PATH, then running python will really work.
Here are your steps:
Right-click Computer and select Properties.
In the dialog box, select Advanced System Settings.
In the next dialog, select Environment Variables. In the User Variables section, edit the PATH statement to include this:
C:\Python27;C:\Python27\Lib\site-packages\;C:\Python27\Scripts\;
Now, you can open a command prompt (Start Menu|Accessories or Start Menu|Run|cmd) and type:
C:\> python
That will load the Python interpreter!
You can install for single user rather than choosing the option of "Install for all users". I was facing the same issue, but when I tried installing just for myself, I was able to install successfully.
I have GNU Emacs 23.4 installed (or, rather, unzipped) into C:\Program Files (x86)\emacs-23.4 on my Win7 64-bit system.
It works fine except that when logged in as a non-administrative user I cannot associate files with the GNU Emacs executeables (I've tried to associate a given file type with runemacs.exe and with emacsclientw.exe). I can browse to the file in the associate dialog, but when I hit "open" it's just ignored.
It works totally fine when I'm logged in as an admin user. (And it worked fine in XP.)
I have found the following: http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/in-windows-7-how-do-i-change-the-open-with/c4a2ad7e-125c-4526-be20-c8f24f18fbfc but I'd prefer to not have to fiddle with registry entries if there's another way to accomplish this.
Any ideas?
If you had a previous version of emacs installed then windows will have associated the name emacsclientw.exe and runemacs.exe with the older version path. To successfully use a new version of emacs you have to remove those associations from the registry with regedit.exe.
Remove the entries:
HKEY_CLASSES_ROOT\Applications\emacsclientw.exe
HKEY_CLASSES_ROOT\Applications\runemacs.exe
Please also see
http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/how-do-i-remove-programs-from-the-other-programs/73a34fc6-b968-429f-9e5e-a0873d67eed9?msgId=1946ffef-cf76-49c6-adb8-0850e1c8610d
I've had the same problem and I've found that the registry entry has to be
emacs-path\bin\emacsclientw -n "%1"
After many attempts to make the GNU Emacs Windows build work to my satisfaction, I always come back to the patched EmacsW32 build. Among other things, it provides an installer that adds file associations and other shell extensions. I've found that it always handles the "Open With" problem correctly. Unfortunately, the latest patched build is of Emacs 23.1.
Same problem trying to associate Allegro Free Physical Viewer rev 16.6 to .brd files.
It turns out that the registry key had the wrong path to the application. I ran regedit navigated to:
HKEY_CLASSES_ROOT > Applications > allegro_free_viewer > shell > open > command
copied out the path and tried that in a CMD window and got path not found (bad path).
I navigated a explore window to the path of the application and copied that path into the registry "command" value, closed regedit, and it worked.