OPNsense Forum
English Forums => General Discussion => Topic started by: litusbdn on February 16, 2017, 01:42:47 pm
-
Good afternoon,
I need to install the following script, to achieve the monitoring of my opnsense through "TrueSight Pulse".
I tried to run the script, but I do not go out with the installation.
I find the following message:
bash: No such file or directory
The script is:
curl -fsS -d '{"token":"XXXXXXXXXXXXXXXXXXX"}' -H 'Content-Type: application/json' https://meter.truesight.bmc.com/setup_meter > setup_meter.sh && chmod +x setup_meter.sh && ./setup_meter.sh
Could you help me?
Thanks!
-
Hi there,
I was afraid that day would come... You need a bash package, but we don't provide it by default.
For now, you can build it locally:
# opnsense-code tools ports
# cd /usr/ports/shells/bash
# make install
What is the opinion of others... should we provide a prebuilt bash package? Not installed by default, but via:
# pkg install bash
Cheers,
Franco
-
I don't know the script but many scripts require bash but would work with sh too. You may try to run it on sh first.
-
Hi,
a prebuild package would be fine. Would save much time.
Regards,
Gunnar
-
Hi there,
I was afraid that day would come... You need a bash package, but we don't provide it by default.
For now, you can build it locally:
# opnsense-code tools ports
# cd /usr/ports/shells/bash
# make install
What is the opinion of others... should we provide a prebuilt bash package? Not installed by default, but via:
# pkg install bash
Cheers,
Franco
I know, “zombie thread,” but I prefer to revive old threads if relevant than create new threads just so that people searching in the future have a easier time.
I would love the option to manually install Bash. I have some custom scripts that I wrote when I got started with OpenWRT. For compatibility I wrote my scripts to be bash compliant as most embedded Linux projects use Ash, Dash, or some other derivative of Bash that has compatible syntax. I have found it easier and more stable to just install Bash on my systems than to rewrite my (now debugged) scripts to the original Bourne Shell.
My two cents are that:
(1) A compiler really shouldn’t be on a router or firewall. So offering prebuilt binary packages is a more secure alternative to instructing users to install from (and therefore compile from) ports.
(2) Requiring users to manually install it from the command line is a fair compromise that reduces the level of support required to be offered by the OPNSense team. Quite bluntly, if I am motivated enough and knowledgeable enough to fire up the command line and manually install extra packages, I am probably the kind of user who can be trusted to install the package without requesting extra support resources.
Of course, I am also the FreeBSD power user who can just edit my pkg.conf file to do what I want. I am just lazy. :P
-
(1) A compiler really shouldn’t be on a router or firewall. So offering prebuilt binary packages is a more secure alternative to instructing users to install from (and therefore compile from) ports.
Err, why? You have several potent scripting languages, shells and/or JIT compilers at your fingertips. As archaic as compiling is the risk is the same or even less especially if you get VPNs and proxies from the packages to exfiltrate data. You can also fetch the sources, or a packaged bootstrap compiler. There are plenty in the binary-compatible package repositories of FreeBSD as you suggest.
Besides, nobody stops anyone from building a commercial or open hardened variant of OPNsense... Or helping us to build a minimal variant that the m0n0wall folks would have loved to see in 2015. :)
(2) Requiring users to manually install it from the command line is a fair compromise that reduces the level of support required to be offered by the OPNSense team. Quite bluntly, if I am motivated enough and knowledgeable enough to fire up the command line and manually install extra packages, I am probably the kind of user who can be trusted to install the package without requesting extra support resources.
As soon as we start adding more shells to packages people will start writing scripts for it. We'll never get rid of them, worst case they start contributing and then we'll have to say "sorry, we don't merge bash" and then people will complain and it's definitely all good with you, but it could take an unfortunate community turn for the worse.
In a similar case we added Ruby and now multiple plugins depend on it for scripts that could have been written in PHP, Python and Perl, all of which are bundled with the default install.
Cheers,
Franco
-
In a similar case we added Ruby and now multiple plugins depend on it for scripts that could have been written in PHP, Python and Perl, all of which are bundled with the default install.
That's different. Ruby was added for my plugins (I don't think anyone else has some of them) ;)
In my opinion, a shell script should be possible in POSIX shell because there is not much difference to bash in most cases. In most other cases, the scripts begin to become bigger where the scripting interpreter which has been named by franco are a lot faster and easier to maintain and contain functions/methods for working with OPNsense like JSON encoding data for configd calls.
And for franco: in case of bash I am sure that it will be used for plugins in the next few weeks if available ;)
-
Please don't get me wrong. I don't think it's bad that we have Ruby. But I do believe it illustrates the problem very well.
Cheers,
Franco