This seems like it should be done in the packaging phase of a job, but the documentation does it in the job's control script.
However when I ssh into the machine the binaries I added to the path are not in the path anymore.
Your assumption is correct, I'm not sure what docs you reference, but binaries should be define in packages
The spec file tells director where in blobs to find the binary:
---
name: bamboo-agent
dependencies:
files:
- bamboo/atlassian-bamboo-5.9.7.tar.gz
And the packaging file tells it where to place those files on the job's vm.
# abort script on any command that exits with a non zero value
set -e
# agent jar is within the full installation tar, pull it out.
tar -xzf $BOSH_COMPILE_TARGET/bamboo/atlassian-bamboo-5.9.7.tar.gz
cp -a atlassian-bamboo-5.9.7/atlassian-bamboo/admin/agent/atlassian-bamboo-agent-installer-5.9.7.jar $BOSH_INSTALL_TARGET/
Control scripts might use those binaries, but should not manipulate them.
See https://bosh.io/docs/create-release.html#pkg-skeletons for an overview of how packages fit into BOSH releases.
Related
I'm new to stackoverflow so correct me if I made any mistake in providing the details.
So I'm trying to make a deb file for Apache-Age, and going by the documentation, if we try to install AGE from source then we can simply do it by :
make install
I have setup the basic directory structure by dh_make and have made the control file with proper dependencies, then comes the rule file.
So I went through 2 different extensions of postgreSQL :
postgresql-q3c
Postgis
And tried to replicate the same for apache-age, and tried to build by following commands
dpkg-buildpackage -rfakeroot -b
dpkg-buildpackage -nc -i
the build was giving some errors and warning but a deb file was generated.
The deb file installed properly but age-extension was not installed in PostgreSQL.
It's probably because the age was not building properly from source using make command as specified in the rule file.
Is there any good resource or how to make rule file ?
I tried following this answer, but got stuck here.
I found a PDF but didn't understand the build process.
This might be a naive way but it works for me:
Clone the repo and cd to it
Run the dh_make_pgxs command to make the debian build directory structure.
The you need to make changes to pgversion, control/control.in, changelog, copyright and rule files.
If you are just trying to use the make file to build the package then the rule file can be as simple as:
#!/usr/bin/make -f
%:
dh $#
Then simply run the build command as before.
I would like to see linux kernel sources that were used to build an image with bitbake in yocto. I need to verify that we are using a correct dts file, and probably to update it.
I was told that devtool can help me to see kernel sources, but I can't understand how to use devtool to get the linux kernel sources(and the dts file in special).
How do I do it?
In order to use devtool to modify the kernel, if you don't know the kernel name, you can execute in the build environment the next command:
devtool modify virtual/kernel
This will modify the recipe for virtual/linux, which underneath is an alias for the kernel you are using, for example linux-tegra, linux-imx, etc.
After you execute that command, you can see the sources that have been unpacked and patched inside your builddir folder on the following path: build/workspace/sources/<kernel recipe name>.
Devtool will create a git repo on that path, which will have the same branches as the remote SRC_URI where it is getting it from, so you can make your changes there.
It will also create a .bbappend so that bitbake knows that the actual source for the kernel is this folder and not the one on tmp. This bbappend is located in this path:
build/workspace/appends/<kernel recipe name>.bbappend
After you modify it, you can just do a bitbake virtual/kernel to build this modified kernel.
In order to find which device tree your machine is using, you can extract such information using the -e flag on bitbake and then grep:
bitbake -e virtual/kernel | grep "^KERNEL_DEVICETREE="
Then you can search for that device tree inside the kernel sources and you can modify it as well.
Hope this helps a little. If you have more doubts let me know.
I have built the TI wilink utilities which then I have integrated in my rootfs. This done using petalinux 2016.4 and have created a install template app in yocto build to copy all the tools and libraries in the rootfs.
When I bring up the BOOT.bin and image.ub, I see the files and libraries but when I try to run for example wpa_supplicant it does not work
even wpa_supplicant -h wont work.
It shows me error:
-sh: /usr/local/sbin/wpa_supplicant: no such file or directory.
The file is present and also has executable permissions.
Do you have any idea why it is not able to run ?
Thanks
Typically, this means that executable file is built for the wrong architecture, i.e. there is a mismatch between the environment where are you running and environment for which you are building. This is how you can make sure they do match or not (execute on target):
# file /usr/local/sbin/wpa_supplicant
...
# uname -m
...
If you see mismatch, then it all boils down to how are you building TI wilink.
I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.
Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.
I'm planing to package WAR files as RPMs. Current deployment process just doesn't work for us and my idea of fixing it would be to create a new Custom Channel in RHN Satellite and publish my WAR files through that Channel. Currently (as we are trying to win some time) I'm managing some config files through Satellite so configs are not a big problem. We don't keep them in WAR for many reasons but that's different story.
Anyway, has anyone packaged WAR as RPMs? Do you do hot deployment or do you force JBOSS/Tomcat to restart? Is that After RPM installation or as a part of it? What's your SPEC file looks like? Can I please see it as an example? Do you check in your SPEC for JBOSS/Java/Oracle client or just install WAR? Any stories to tell? Any major problems?
Should I consider something else?
I can build RPMs no problem but I'd like to hear what's the best way of doing this with WAR files and JBOSS (some Tomcats are still running here but they will be phased out soon-ish so I'm not too worried about them).
I do appropriate any input.
Thanks in advance
Kind Regards
Chris
I have packaged a WAR file and its companion config file as RPM. My SPEC file checks whether JBoss is running. If it is, the installation exits with an error message, requesting that JBoss be stopped before installation.
In general, it is not a good idea to kill processes or force restart through RPMs. The person in charge of installation should have a separate procedure for doing this.
Other considerations:
1. Does your organization have other installations on the same server?
If so, you might want to standardize on a path under which all installations on the server will go. (For example, /usr/local/bin/myorg/)
It might also help to have a custom *nix user and group, for which file attributes are set for all installations on the server.
2. Do you want a relocatable RPM?
Is there ever a chance that you might want to change the default path for your installation? If so, a relocatable RPM will help.
There are conditions where a relocatable RPM may not work, so check out these things to consider at www.rpm.org.
3. Do you want to back up an existing deployment when your RPM runs?
If so, you would need to write that code in your SPEC file.
Here is my complete SPEC file:
Summary: Summary for my Java project
Name: Name for my Java project
Version: 2.1.2
Release: 5
Requires: jboss >= 5.1
BuildArch: noarch
Group: Internet / Applications
Prefix: /usr/local/bin
License: (C) Copyright my organization
Vendor: my organization
%description
Description for my Java project
%prep
# Check if the WAR file has been created
%install
# Copy war file to buildroot's Jboss deployment directory
# Copy config file to buildroot's Jboss config directory
%files
# Set file permissions and ownership
%pre
# Check if JBoss deployment path exists on the web server.
# If not, exit with an error.
# Check if JBoss config file path exists on the web server.
# If not, exit with an error.
# Check if custom user 'myuser' exists. If not, exit with an error.
# Check if custom group 'mygroup' exists. If not, exit with an error
# Check if JBOSS is running. If yes, exit with an error.
# Take backup of existing deployment, if needed.
%post
# Perform post-installation steps, if needed.
echo "Installation complete."
We plan to somehow standardize Java webapp installation on Fedora, but there is nothing yet.
Debian guys created a rather nice proposal http://dep.debian.net/deps/dep7 which you should probably read to get an idea what you'd have to deal with more or less.
As for JBoss/Tomcat restart, I would advise against it. Leave it to the system (webserver) administrator. They should know what they are updating and why. Forcing restart of webserver all the time is asking for trouble IMO (especially if one server is hosting multiple webapps)
I would put the wars in /usr/share/webapps-java. Then probably have JBoss/Tomcat use that directory. That said, no spec files, sorry.