In which directory should I compile from source?

I have downloaded the sources of Bacula 7.2.0 as I don’t find that program in any repo.

My questions are:

  • Where should I put the source files before running compilation?
  • Does the compiler take care where to put the output (compiled binary) files or if not - where should I manually move them?
  • How do I proceed with upgrades in the long term when something like this is not installed from RPM but from source?
  • Is it possible that I create an RPM of the final result for easier installation afterwards? (maybe we can include it in some repo afterwards? no idea how this works…)

Anywhere you like. Of course you need write access to this directory. It is usually discouraged to compile as root.

  • Does the compiler take care where to put the output (compiled binary) files or if not - where should I manually move them?

Compiler?!? Of course not. Compiler takes care about compilation. Most projects come with Makefiles containing something like “install” target that installs binaries after they are built. Consult documentation for your software.

  • How do I proceed with upgrades in the long term when something like this is not installed from RPM but from source?

Assuming your project provides “uninstall” target and you still have originally configured Makefile for current version I would do “make uninstall” followed by “make install” of new version. Consult documentation for your software.

  • Is it possible that I create an RPM of the final result for easier installation afterwards? (maybe we can include it in some repo afterwards? no idea how this works…)

Yes; actually there is 7.2 project for 42.1 (see software.opensuse.org); you may consider cooperating with this user and submitting it to primary repository Archiving:Backup.

Thanks for explaining. I hope you don’t mind me asking a bit more.

Considering this:

[QUOTE=arvidjaar;2747281]Anywhere you like. Of course you need write access to this directory. It is usually discouraged to compile as root.
[/QUOTE]

does “make install” take care of proper file ownership and permissions? What does only “make” do?

Assuming your project provides “uninstall” target and you still have originally configured Makefile for current version I would do “make uninstall” followed by “make install” of new version. Consult documentation for your software.

Hm. Looking at the documentation it seems they actually recommend not to run “make uninstall”.

Yes; actually there is 7.2 project for 42.1 (see software.opensuse.org); you may consider cooperating with this user and submitting it to primary repository Archiving:Backup.

Searching for bacula leads me here:

http://software.opensuse.org/package/bacula

and in subsection Leap 42.1 I see home:gody Source rpm. I suppose this means only the sources are in this package? How do I proceed to cooperate with someone as you suggest?

it does whatever is written in makefile. I have no idea what it does in your specific case.

Looking at the documentation it seems they actually recommend not to run “make uninstall”.

You see, reading documentation pays off :slight_smile:

I suppose this means only the sources are in this package?

Did you try to click on this link? There are binary RPMs for a lot of Linux flavors.

How do I proceed to cooperate with someone as you suggest?

You can always (try to) contact author by e-mail for a start … of course if you have something to offer :slight_smile:

Actually I just found this:

http://software.opensuse.org/download.html?project=home%3Agody&package=bacula

and there are compiled RPM’s.

But I wonder - why is that not in the Archiving:Backup?

I don’t have the email address of the person and don’t know where to get it. But I already wrote on this page and there is no reply.

I would be glad to help with whatever I can but how does this whole thing with the repos work?

Hi
Have a read here;
http://lists.opensuse.org/opensuse-project/2015-10/msg00062.html

https://software.opensuse.org/package/bareos

For contact details;
https://build.opensuse.org/package/show?project=home%3Agody&package=bacula
and check the changelog for an email address;
https://build.opensuse.org/package/view_file/home:gody/bacula/bacula.changes?expand=1

If that doesn’t work, click on users and follow the lefthand link;
https://build.opensuse.org/package/users/home:gody/bacula

If you really wanting to compile, then first stop is the spec file for the configure options (there are a few) before running make;
https://build.opensuse.org/package/view_file/home:gody/bacula/bacula.spec?expand=1

[QUOTE=malcolmlewis;2747313]Hi
Have a read here;
http://lists.opensuse.org/opensuse-project/2015-10/msg00062.html
[/QUOTE]
Yes, I have already been there.

openSUSE Software

I have been playing with Bareos but it cannot even label my tape. Unfortunately their mailing list did not help. They offer to look into “my problem” if I pay 290eur for yearly subscription (cough). I have never had tape problems with Bacula, so I decided to look for a way to install latest Bacula on Leap.

For contact details;
https://build.opensuse.org/package/show?project=home%3Agody&package=bacula
and check the changelog for an email address;
Show home:gody / bacula - openSUSE Build Service

If that doesn’t work, click on users and follow the lefthand link;
Users of bacula (Project home:gody) - openSUSE Build Service

Thanks.

If you really wanting to compile, then first stop is the spec file for the configure options (there are a few) before running make;
Show home:gody / bacula - openSUSE Build Service

Ok I will try to easy way first. Thanks again!

It seems there are quite a few issues with that hosted 7.2.0 on the repo. I have tried to contact the person and waiting for a reply.

I might try to compile though. But how do I use this info:

Hi
What are the issues as this may impact your compile options…?

It was impossible to start any of the DIR, FD or SD services from YaST or from command line (I am using the exact same config files as in 5.2.13). Looking at journalctl I saw:

Jan 07 19:50:02 i7 systemd[1]: bacula-dir.service never wrote its PID file. Failing.
Jan 07 19:50:02 i7 systemd[1]: Failed to start Bacula Director Daemon service.

Obviously bacula could not create it’s PID files in /var/run because that directory is owned and writeable by root only.

Then I found this info and manually changed the systemd bacula-*.services to use User=root. Originally they were set to use User=bacula. One of the services even had User= and Group= (both empty). I can’t recall if it was FD or SD but I fixed them both to be User=root Group=bacula.

I am not an expert in systemd and I really don’t know if setting a service to run as root this way is appropriate. I suppose it is just some workaround. Bacula 5.2.13 never had this problems, neither did Bareos. But as I mentioned they have other issues - Bacula 5.2.13 doesn’t respect the Exclude Dir Containing option and Bareos can’t label the tapes. That is the main reason I decided to move to latest Bacula.

Anyway with that workaround in services now FD and SD can be started from YaST. But for DIR I am still getting errors. In /var/log/bacula/bacula.log:

07-Jan 20:19 bacula-dir JobId 0: Fatal error: Please replace this null libbaccats library with a proper one.
07-Jan 20:19 bacula-dir JobId 0: Fatal error: Could not open Catalog "MyCatalog", database "bacula".
07-Jan 20:19 bacula-dir ERROR TERMINATION
Please correct configuration file: /etc/bacula/bacula-dir.conf

I don’t know why this happens. The DB credentials and permissions are correct as they obviously worked in the same config when used in Bacula 5.2.13. As for the libbaccats thing - after a some Google searching I found people checking for dependencies this way, so I did that too:

# ldd -v /usr/lib64/libbaccats-7.2.0.so 
        linux-vdso.so.1 (0x00007ffd55d4b000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fd00180d000)
        /lib64/ld-linux-x86-64.so.2 (0x0000565165176000)


        Version information:
        /usr/lib64/libbaccats-7.2.0.so:
                libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
        /lib64/libc.so.6:
                ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
                ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

However I don’t know how to use this info and if this output shows any actual problem.

I also notice is that rcbacula-dir, rcbacula-fd and rcbacula-sd are not available as cli commands. No idea what the reason for that might be.

Hi
Quite a few… :wink: In the first instance I suggest waiting for a reply from the home user and their package.

I also note that bareos has a label and update slots command (according to the documentation)?

:slight_smile: That’s exactly what I am doing + waiting for a reply on a bug report on Bareos. They seem to question some block size discrepancy.

I also note that bareos has a label and update slots command (according to the documentation)?

The label is the root problem because of which I cannot use Bareos. As for update slots - I don’t have an autochanger.

Hi
Looking further I see it’s a linked package. The original is at;
https://build.opensuse.org/package/show/home:aevseev/bacula

I suggest you install the version from here;
http://download.opensuse.org/repositories/home:/aevseev/openSUSE_42/

Then see how it all goes, the above project has a complete project config, the project you used doesn’t which could be causing issues.

Thanks.

What do you mean by project config?

compared to;

Now in saying that, looking at the build log it does show some systemd warnings that should be fixed (well I would);
https://build.opensuse.org/build/home:aevseev/openSUSE_42/x86_64/bacula/_log

I also note that have you started the relevant systemd services and checked the status?

If I had a way to test (I do have tape drives, but on sparc systems :wink: ) I could probably help more, but hopefully the maintainer/packager can assist better since I’m assuming they are using it…

The likely better way to discover dependencies and how to build is to follow the Bacula documentation.

Note that it’s a separate download from the main source files (you can get both at the following link)
http://sourceforge.net/projects/bacula/files/bacula/7.2.0/

Unfortunately, it looks like just unpacking and deploying the documentation is itself an exercise, after you unpack the documentation’s files, your first step should always be to read the README file and in this case it lists the documentation’s dependencies (latex2html, te_latex, tetex) and copy files to a running website (your choice. You can install and deploy an Apache website or I strongly recommend instead a nodejs or similar webserver if you know how. See my “How To” for installing nodejs at the end if you want to do this).

Not all, but most major projects nowadays have documentation even newbies might be able to follow.

TSU

https://en.opensuse.org/User:Tsu2/nodejs

Looks like node.js changed their homepage which described invoking a simple webserver in a few seconds. Their official guide is a bit more complicated but is nuts and bolts. Simply put, create or copy the provided answer file, copy your website files to the correct location, invoke “createserver” and you’re cooking. Once you’ve done it, you’ll never use something big like Apache to simply launch a simple, temporary website like for Bacula’s documentation
https://nodejs.org/en/docs/guides/anatomy-of-an-http-transaction/

One solution is to change service to create PID file in subdirectory (like /run/bacula) and pre-create this subdirectory with correct permissions using either tmpfiles snippet or ExecStartPre in service.

Then I found this info and manually changed the systemd bacula-*.services to use User=root.

I do not know bacula internals, but usually you should always run your service with the least privileges possible. If this service does not need root, do not run it as root.

[QUOTE=malcolmlewis;2747406]Project Configuration of home:gody - openSUSE Build Service
compared to;
Project Configuration of home:aevseev - openSUSE Build Service
[/QUOTE]
It seems home:gody and home:aevseev are the same user as the later matches the email address in the logs which you previously showed. However I still have no answer. I will try the second repo and see if the result is different.

BTW I now recall another discrepancy I found: the files /usr/sbin/bacula-* had owner root.root which I had to change to root.bacula to make it work as it was throwing a permission error in journal and couldn’t work at all.

Now in saying that, looking at the build log it does show some systemd warnings that should be fixed (well I would);
Welcome - openSUSE Build Service

I also note that have you started the relevant systemd services and checked the status?

Sure. FD (file daemon) and SD (storage daemon) work. But DIR (the Director) which rules them all cannot even start as I have pasted in a previous post.

If I had a way to test (I do have tape drives, but on sparc systems :wink: ) I could probably help more, but hopefully the maintainer/packager can assist better since I’m assuming they are using it…

Yes, I am looking forward to it.

[QUOTE=tsu2;2747425]The likely better way to discover dependencies and how to build is to follow the Bacula documentation.

Note that it’s a separate download from the main source files (you can get both at the following link)

Unfortunately, it looks like just unpacking and deploying the documentation is itself an exercise, after you unpack the documentation’s files, your first step should always be to read the README file and in this case it lists the documentation’s dependencies (latex2html, te_latex, tetex) and copy files to a running website (your choice. You can install and deploy an Apache website or I strongly recommend instead a nodejs or similar webserver if you know how. See my “How To” for installing nodejs at the end if you want to do this).

Not all, but most major projects nowadays have documentation even newbies might be able to follow.

TSU
[/QUOTE]
I know that but I haven’t gone into those complications as the documentation is available online anyway.

[QUOTE=arvidjaar;2747443]One solution is to change service to create PID file in subdirectory (like /run/bacula) and pre-create this subdirectory with correct permissions using either tmpfiles snippet or ExecStartPre in service.
[/QUOTE]
I have been thinking the same. However considering so many “hacks” need to be used as workarounds I am questioning the ease of maintenance of such system in the long term (considering that this path is also in the *.service files as well as in the *.conf ones). With Bacula 5.2.13 I never had these problems and there was no need for making things so very custom in every sense just to make the software work.

I do not know bacula internals, but usually you should always run your service with the least privileges possible. If this service does not need root, do not run it as root.

That’s what I thought. I really don’t know why it can’t start as user ‘bacula’ though. Is that something that needs to be fixed during compilation or ‘make install’?

I am going to make a few more tests before attempting to build the whole thing myself. But I am really trying to avoid making anything hard to maintain in the long term.

Ok, I tried setting the PID to a directory where Bacula can write - changed this both in /etc/bacula/bacula-.conf and /usr/lib/systemd/system/bacula-.services files. Same unfortunate result. The only difference is that now I could run the FD and SD services as user bacula but without a running DIR this is useless.

Then I removed all bacula packages, removed the repo home:gody and installed from home:aevseev. Result: exactly the same problems.

Considering all that and that it was mentioned that these issues affect the options I sould use for compilations - what options should I use actually?

First,
I don’t know if you noticed that Bacula released 7.2.1-0 day before yesterday (as of this writing).

Also,
Besides what is likely in the source, the following is an informal description of requirements. AFAIK, a default LEAP with the Development C pattern satisfies.
http://blog.bacula.org/general/system-requirements/

I assume that you’re downloading source from sourceforge.
Taking a look at the project, it looks like although the source is “also” posted at sourceforge, the master copy and recommended is at bacula’s git repos since 2009

How to clone latest bacula source and compile is at the following link. It’s mainly written for Dev/Contributors, so ignore all the stuff about pulling to update to latest, creating a new branch, etc. Just clone the repo, run “./configure,” make and likely “make install.”
http://www.bacula.org/7.0.x-manuals/en/developers/Bacula_Git_Usage.html

Commenting on previous posts in this thread,

Although most apps should be compiled and run with least privilege, I’m not so sure that should apply to Bacula. Bacula is an Admin type tool which requires root level permissions to perform (access to all file systems across the Enterprise regardless of User and often beyond normal User permissions). So, I’d actually suggest compiling in a root console and running as root. I don’t even know if sudo would provide sufficient permissions across the Enterprise.

As for <where> to compile, I don’t know if that should matter unless the compile targets a location within its own file tree. I would instead expect that the target location should default to some location like /opt (which again requires root permissions to write). Once the app has been compiled and installed, ordinarily you should be able to remove the source files if you wish.

TSU