im following this guide to install OpenVPN on my FreeNAS system.
http://joepaetzel.wordpress.com/2013/09/22/openvpn-on-freenas-9-1/
I have ran in to the issues detailed below when trying to create the CA.cert.
[root#freenas] /mnt/NAS/openvpn# chmod -R 755 easy-rsa/2.0/*
[root#freenas] /mnt/NAS/openvpn# cd easy-rsa/2.0
[root#freenas] /mnt/NAS/openvpn/easy-rsa/2.0# sh
#./clean-all
Please source the vars script first (i.e. "source ./vars")
Make sure you have edited it to reflect your configuration.
# . ./vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /mnt/NAS/openvpn/easyrsa/2.0/keys
# ./build-ca
Please edit the vars script to reflect your configuration,
then source it with "source ./vars".
Next, to start with a fresh PKI configuration and to delete any
previous certificates and keys, run "./clean-all".
Finally, you can run this tool (pkitool) to build certificates/keys.
I have tried creating the keys directory manually as i have read this has worked for others but still no luck. Being new to BSD I've hit a road block and looking for some advice.
Any ideas?
cheers guys
UPDATE:
When trying to source ./vars i get the following output
[root#freenas] /mnt/NAS/openvpn/easy-rsa/2.0# source ./vars
export: Command not found.
export: Command not found.
export: Command not found.
export: Command not found.
EASY_RSA: Undefined variable.
export: Command not found.
EASY_RSA: Undefined variable.
FreeNAS's default shell is not sh, and therefore doesn't support the 'export' command. The ./vars script needs the export command to set environment variables it then needs.
So before you call ./vars (don't call source) call:
sh
This is clearly stated in the site: http://joepaetzel.wordpress.com/2013/09/22/openvpn-on-freenas-9-1/
Not sure about the original issue, i think nrathaus has covered that well.
demonLaMagra - If you want to check if openvpn in running use this command:
service openvpn status
Sorry I couldn't comment on the last answer because of being a new new user, otherwise I would have.
Related
I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
I've tried cloning eopen from this link https://github.com/ko1nksm/eopen-ecd into my local user directory and added this line of code: eval "$(sh "/home/user/eopen-ecd/init.sh")" into the .bashrc as instructed in the Installation guide. After resetting my wsl terminal, this following error is shown:
[eopen-ecd] ebridge.exe not found or is not executable.
Place ebridge.exe and enter the following command.
chmod +x '/home/user/eopen-ecd/bin/ebridge.exe'.
The error shows every new instance of the bash terminal.
Download the archive containing ebridge.exe from here and place it in the appropriate path.
I finally got it to work! The instruction was in the error message all along...
...
Place ebridge.exe and enter the following command.
chmod +x 'home/user/eopen-ecd/bin/ebridge.exe'
Just follow the instructions above after downloading eopen-ecd from this link and viola! Problem solved!
I am trying to compile these library into my android code https://sdk.dronecode.org/en/contributing/build.html . This library has C/C++ written code. Therefore NDK will be used here.
When I try to hit the command sudo make android install I get this error:
Makefile:152: *** NDK_ROOT is undefined, please point the environment variable to android-ndk root.. Stop.
I have set the environment variable into my .bashrc file . But still getting this error, please help me out to get this compiled. I am using ubuntu 16.04. I have checked the other links "NDK_ROOT not defined. Please define NDK_ROOT in your environment" but couldn't helped much.
sudo does not source .bashrc
You can try directly running the command with your env explicitly defined
i.e. sudo NDK_ROOT=xxxxx make android install
or follow the advices here, using .profile
I am trying to setup a JProfiler Agent on Remote AWS Linux.
I followed the steps from #### Method 2: Add agentpath to JAVA_OPTS.
But I get the following error:
The file is on drive. I can navigate to it.
What did I do?
I downloaded the JProfiler10.0.4 as targz for Linux.
Unzip the archive
Executed the command nano ~/.bashrc
I modified the content in this way.
Executed the command source ~/.bashrc
I get the error.
Do you have any idea what I am doing wrong?
Thank you
It looks like you're actually trying to set JAVA_OPTS.
Todo that you have assign it to JAVA_OPTS and then export it. In your .bashrc, replace -agentpath:"$jpPath" with this:
export JAVA_OPTS="-agentpath:$jpPath"
#crea1 is right, but I would really not use the method of modifying JAVA_OPTS. It's better to pass the -agentpath VM parameter to the VM that you are trying to profile by modifying the start script.
I just installed sdkman for installing grails on my machine (MacOS). When I run which sdk command I don't get any output. But when I run the sdk help command the shell is able to resolve it and give the right output. I checked all the directories mentioned in $PATH environment variable but I could not find any executable sdk. So my question is how is shell able to resolve the sdk command?
Note: I also checked in Ubuntu and I see the same behavior.
As you mentioned correctly "sdk" is not a command, its a declared function created by sdkman-main.sh (in ~/.sdkman/src) once called from ~/.sdkman/bin/sdkman-init.sh
This is the reason why the installation page of sdkman asks for appending the following steps in the .bash_profile which declares this function each time the bash profile is loaded :
#THIS MUST BE AT THE END OF THE FILE FOR SDKMAN TO WORK!!!
[[ -s "/home/dudette/.sdkman/bin/sdkman-init.sh" ]] && source "/home/dudette/.sdkman/bin/sdkman-init.sh"
This is also the reason "which" command doesn't pick it up as it checks for the installed commands on the linux PATH
OK. So I found it out. As #that-other-guy mentioned in the comment above, I used type -a instead of which, which showed me that it was a function defined.