I am trying to write some tests for a chef Nginx cookbook. I have come to a block. I need to write a test for the code below. I can test for the core_lock released. I am unsure how to test for the make install as well as ./autogen.sh and ./configure --enable-standalone-module
The docs have not been too helpful since this is a bash command the docs are a bit sparse.
Code need test for
bash 'compile_modsecurity' do
cwd modsec_compile_path
code <<-EOH
./autogen.sh
./configure --enable-standalone-module
make
make install
EOH
action :nothing
notifies :run, 'bash[release_core_nginx_lock]', :immediately
end
You would write an InSpec test block that uses a command resource to try and actually run nginx. Usually you do this with something like --version and then confirm that it looks correct. You can then try starting the service and use an http_request resource to connect to it on localhost and get some content.
Related
I am trying to use a shell script as a custom shell in Github Actions like this:
- name: Test bash-wrapper
shell: bash-wrapper {0}
run: |
echo Hello world
However, when I try to run it, I get Permission denied.
Background: I have set up a chroot jail, which I use with QEMU user mode emulation in order to build for non-IA64 architectures with toolchains that lack cross-compilation support.
The script is intended to provide a bash shell on the target architecture and looks like this:
#!/bin/bash
sudo chroot --userspec=`whoami`:`whoami` $CROSS_ROOT qemu-arm-static /bin/bash -c "$*"
It resides in /bin/bash-wrapper and it thus on $PATH.
Digging a bit deeper, I found:
Running bash-wrapper "echo Hello world" in a GHA step with the default shell works as expected.
Running bash-wrapper 'echo Running as $(whoami)' from the default shell correctly reports we are running as user runner.
Removing --userspec from the chroot command in bash-wrapper (thus running the command as root) does not make a difference – the custom shell gives the same error.
GHA converts each step into a script file and passes it to the shell.
File ownership on these files is runner:docker, runner being the user that runs the job by default.
Interestingly, the script files generated by GHA are not executable. I suspect that is what is ultimately causing the permission error.
Indeed, if I modify bash-wrapper to set the executable bit on the script before running it, everything works as expected.
I imagine non-executable script files would cause all sorts of troubles with various shells, thus I would expect GHA would have a way of dealing with that – in fact I am a bit surprised these on-the-fly scripts are not executable by default.
Is there a less hacky way of fixing this, such as telling GHA to set the executable bit on temporary scripts? (How does Github expect this to be solved?)
When calling your script try running it like this:
- name: Test bash-wrapper
shell: bash-wrapper {0}
run: |
bash <your_script>.sh
Alternatively, try running this command locally and the commit and push the repository:
git update-index --chmod=+x <your_script>.sh
I wrote a small test project for Singularity Compose, consisting of a small server application, with the following YAML file:
version: "1.0"
instances:
server:
build:
context: ./server
recipe: server.recipe
ports:
- 9999:9999
When I call singularity-compose build, it successfully builds server.sif. Calling singularity-compose up also seemingly works without error, and calling singularity-compose ps results in something that looks just fine:
+ singularity-compose ps
INSTANCES NAME PID IMAGE
1 server 4176911 server.sif
However, the server application does not work, calling my test client results in it saying that there is no answer from the server.
But if I run server.sif directly without compose, everything works just fine.
Also, I tripple checked, my test application listens to port 9999, thus should be reachable from the outside.
What did I do wrong?
Edit:
I also checked whether there actually is any process listening at port 9999 by calling sudo lsof -i -P -n | grep LISTEN, this is not the case. Only when I manually start server.sif without compose it shows me the process listening.
Edit:
I went into the Singularity Compose shell and tried to start the Server application directly in there, just as a test, and it resulted in Permission denied. Not sure if that means anything.
Edit:
I now gave the application execution rights within the shell and called in there, this works. Am now trying to add execution rights in the recipe. If that works, it would be kind of strange, as the executable was build right there, and thus should already have execution rights.
Edit:
I added chmod +x in my recipe both after building Server and before executing it. Doesn't work either.
Also checked whether any bridges exist using brctl show, this is not the case.
Edit: My recipe, adjusted by the input of tsnowlan in his answer below:
Bootstrap: docker
From: ubuntu:20.04
%files
connection.cpp
connection.h
main.cpp
server.cpp
server.h
server.pro
%post
# get some basics
apt update
apt-get install -y wget
apt-get install -y software-properties-common
# get C++ compiler
apt-get install -y g++
apt-get install -y build-essential
apt-get install -y build-essential cmake
# get Qt
apt-get install -y qt5-default
# compile
qmake
make
ls
%runscript
/Server
%startscript
/Server
Again, note that the application works just fine both when compiled and startet normally and when started within a Singularity image (but without Singularity Compose).
The ls at the end of the %post block is used to verify that the Server application was build successfully.
Please share the server.recipe, as it is difficult to identify should be/is happening without it.
Without having that, my guess is that you have a %runscript in your definition file, but no %startscript. When the image is executed directly or via singularity run image.sif, the contents of %runscript determine what happens. To emulate the docker-compose style, the singularity images are started as persistent instances. In this case, the %startscript block determines what runs. If it is empty, it will just start up and sit there doing nothing. This would explain why when run by hand it works but not when using compose.
After installing Intellij Idea using flatpak on Clear Linux I'm not able to make it run svn executable.
I added ---filesystem=host to flatpak permissions and tried to set executable path to /run/host/usr/bin/svn but with no luck (path is available/exists, though Intellij keeps complain)
svn command is normally available from system terminal.
When I try to run /run/host/usr/bin/svn command via Intellij Idea built-in terminal, I've got error that library is not available:
sh-5.0$ /run/host/usr/bin/svn
/run/host/usr/bin/svn: error while loading shared libraries: libsvn_client-1.so.0: cannot open shared object file: No such file or directory
I also tried set flatpak-spawn. Following command works perfectly fine in Intellij Idea built-in terminal:
/usr/bin/flatpak-spawn --host /usr/bin/svn, though when set as path to svn executable still gives me Intellij Idea error:
"The path to Subversion executable is probably wrong"
Could anybody please help with making it work?
TLDR: You probably need to add the path to svn into your IntelliJ terminal Path.
Details:
It looks like you are having a path issue. I had a similar problem running kubectl running PyCharm installed from a flatpak on Pop_Os.
If I try to run kubectl I see the following:
I have kubectl installed in /usr/local/bin. This is a screenshot from my 'normal' terminal.
In the PyCharm terminal this location is mounting under /run/host/usr/local/bin/.
If I look at my path in the PyCharm terminal, it is not there.
So I'll add the /run/host/usr/local/bin/ to my path and I can then run kubectl:
To make sure this comes up all the time, I need to add the PATH to the Terminal settings:
I can now execute any of the commands in my /usr/local/bin dir.
I found a really ugly solution for dealing with SVN with the JetBrains family, which does actually answer the question. But in a very roundabout way. Unfortunately Alex Nelson's solution didn't work for me.
You would think the Flatpak would come with a valid SVN, since it's actually part of the expected requirements for the program...
When in the terminal, you can run
cd ..
/usr/bin/flatpak-spawn --host vim ./svn
Then press i to go into input mode, then paste the following in the opened text file (Basically what it does is create an executable which passes it to the flatpak-spawn invocation):
#!/bin/bash
/usr/bin/flatpak-spawn --host /usr/bin/svn $#
Save and quit from vim (ESC, then :wq!). Make it executable:
chmod +x svn
Then in IntelliJ's menu, set the "path to svn" to
/home/<yourusername>/IdeaProjects/svn
It's worked for everything I've tried... Hope this helps out anyone else who was struggling with this.
I am using a similar solution to caluga.
#!/bin/sh
cd
exec /usr/bin/env -- flatpak-spawn --host /usr/bin/env -- svn "$#"
exec makes it replace the wrapper script process so the wrapper script process can end.
I'm using /bin/sh instead of /bin/bash as bash features are not needed.
using /usr/bin/env, but maybe not necessary if PATH is set up right.
remember to quote "$#" in case there are spaces in arguments.
I am putting it in ~/.local/bin and referencing it with its absolute path in the IntelliJ settings (Settings -> Version Control -> Subversion -> Path to Subversion executable).
I also was running into problems with IntelliJ saying that /app/idea-IC path does not exist. Figured that something outside the flatpak (i.e. svn or env) was trying to change directory to the working directory from where the wrapper script was invoked (inside the flatpak). Using cd allows the wrapper script to change to a directory that exists both inside the flatpak and on the host.
Fedora Silverblue or toolbox users might want to use dev tools inside their toolbox, in which case you can do:
#!/bin/sh
cd
exec /usr/bin/env -- flatpak-spawn --host toolbox run svn "$#"
I have a package that is using the autotools to build and install.
Part of the package is a website that can be run on the local machine.
So in the package there is a .conf file that is meant to be either
copied or linked to the /etc/apache2/conf.d directory. What's the
standard way that packages would do this? If possible, I'd like for
the user not to have an extra step to make the website work. I'd like
to have them install the package and then be able to browse to
http://localhost/newpackage to get up and running.
Also, is there a way that autoconf knows about the apache install or a
standard way through then environment some how? If someone could
point me in the right direction that would be great.
Steve
The first thing you should do is to locate the apache extension tool apxs or apxs2 (depends on apache version and/or platform you are building for). After you know where your tool is located you can run queries to get certain apache config params. For example to get system config dir you can run:
apxs2 -q SYSCONFDIR
Here is a snippet of how you can locate apache extension tool: (be careful it may contain syntax errors)
dnl Note: AC_DEFUN goes here plus other stuff
AC_MSG_CHECKING(for apache APXS)
AC_ARG_WITH(apxs,
[AS_HELP_STRING([[--with-apxs[=FILE]]],
[path to the apxs, defaults to "apxs".])],
[
if test "$withval" = "yes"; then
APXS=apxs
else
APXS="$withval"
fi
])
if test -z "$APXS"; then
for i in /usr/sbin /usr/local/apache/bin /usr/bin ; do
if test -f "$i/apxs2"; then
APXS="$i/apxs2"
break
fi
if test -f "$i/apxs"; then
APXS="$i/apxs"
break
fi
done
fi
AC_SUBST(APXS)
The way to use APXS in your automake Makefile.am would look something like this:
## Find apache sys config dir
APACHE2_SYSCONFDIR = `#APXS# -q SYSCONFDIR`
## Misc automake stuff goes here
install: install-am
cp my.conf $(DESTDIR)${APACHE2_SYSCONFDIR}/conf.d/my.conf
I assume you are familiar with automake and autoconf tools.
First steps in FreeBSD: trying to run my installation script. Fast help needed:
# ls
configure
# file configure
configure: Bourne-Again shell script text executable
# ./configure
./configure: Command not found
# configure
configure: Command not found
What is wrong, how can I execute this script?
Do you have bash installed? If not use FreeBSD Ports to install it. Use where bash to find out.
Use the force Luke :)
# pkg_add -r bash
May it be, that your's configure script doesn't have appropriate executions rights. Try to cast:
chmod 777 configure
If it works, fix it to
chmod 764 configure
configure scripts are ultra portable shell scripts. There is no need for bash here. The problem is somewhere else.
What's the first line in the configure script? Maybe a CR/LF snuck in, which is a common cause for a totally misleading error message saying that the script was not found, when it was the interpreter that was not found.
Please try /bin/sh ./configure
Install the bash package using
pkg add bash
or
make -C /usr/ports/shells/bash install clean
By default FreeBSD comes with tcsh and a POSIX compatible FreeBSD sh
On older FreeBSD systems you will need to do
rehash
before you can run it.
First line of this script (#!/usr/bin/bash, i suppose) should be changed to #!/usr/local/bin/bash.
And of course, you should have shells/bash port installed.