Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
Daniel Bareiro wrote: > Hi, Joseph. > > On Thursday, 12 August 2010 20:00:29 +, > Joseph L. Casale wrote: > > > I've been following this thread in hopes of uncovering the reason why > > the op would even compile himself for a platform that has precompiled > > binaries available (lets forgo the obvious argument for destroying a > > package managed Cadillac OS in the first place) and I haven't seen it > > appear? > > > Why the need to endure all this pain in the first place? Even if > > compile time options needed to be changed, wouldn't it be > > easier/smarter/faster/lighter/shinier to modify the spec and rebuild? > > I'm compiling Bacula because after searching on the official > repositories of CentOS 5.5, I did not find precompiled binaries. Luckily > I was able to solve this problem, although in the past days I was busy > with other things and so I could not continue with this thread. > Pre-compiled binaries are offered through Fedora Project's EPEL repository, for which you can find the necessary information on: http://fedoraproject.org/wiki/EPEL Kind regards, Jeroen van Meeuwen -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
On Wednesday, 11 August 2010 01:17:11 -0300,
Daniel Bareiro wrote:
> > > It looks like you are running a 64-bit bacula-sd, so the libraries
> > > should be in /usr/lib64.
> > >
> > > The files you found are in /usr/lib, which are normally 32-bit.
> > > Either you have the 32-bit libraries installed by accident or the
> > > 64-bit libraries are installed in the wrong place (broken rpm?).
> > Indeed, I'm using CentOS 5.5 amd64. I was not doing the installation
> > with RPM packages, but compile the source code obtained at the
> > official site of Bacula. On sunday, doing tests comparing with the
> > installation done with packages RPM, I realized that the difference
> > was in which the libraries were in /usr/lib64.
> >
> > Doing again the configuration using this time the
> > --libdir=/usr/lib64 parameter, the problem was not reproduced. What
> > it is strange to me is that in an installation of Debian Lenny
> > amd64, I didn't do the configuration using --libdir=/usr/lib64 and
> > in spite of putting the libraries in /usr/lib, I did not have the
> > problem occurred in CentOS.
> I already found the cause:
>
> # ll /usr/lib
> lib/ lib32/ lib64/
> # ll -d /usr/lib
> drwxr-xr-x 41 root root 20480 ago 8 01:56 /usr/lib
> # ll -d /usr/lib32
> lrwxrwxrwx 1 root root 24 abr 11 2009 /usr/lib32 -> /emul/ia32-linux/usr/lib
> # ll -d /usr/lib64
> lrwxrwxrwx 1 root root 3 abr 11 2009 /usr/lib64 -> lib
Just now I can return to this thread after several days in which I was
busy with other things.
Well, after having found and determined the cause of the problem with
the libraries, to try to make a backup of the catalog I get the
following error:
---
29-ago 17:03 bacula-dir JobId 51: shell command: run BeforeJob
"/etc/bacula/scripts/make_catalog_backup.pl MyCatalog"
29-ago 17:03 bacula-dir JobId 51: BeforeJob: Can't get catalog information at
/etc/bacula/scripts/make_catalog_backup.pl
line 129.
29-ago 17:03 bacula-dir JobId 51: Error: Runscript: BeforeJob returned non-zero
status=13. ERR=Child
exited with code 13
29-ago 17:03 bacula-dir JobId 51: Error: Bacula bacula-dir 5.0.2 (28Apr10):
29-ago-2010 17:03:52
---
Assuming it was a permissions problem accessing the database, locate the
line in question (108):
exec("HOME='$wd' mysqldump -f --opt $args{db_name} > '$wd/$args{db_name}.sql'");
and I tried to pass a configuration file so that from this the data are
taken:
exec("HOME='$wd' mysqldump --defaults-file=/etc/bacula/.my_bacula.cnf -f \
--opt $args{db_name} > '$wd/$args{db_name}.sql'");
but I continue getting the same error.
Regards,
Daniel
--
Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37
Powered by Debian GNU/Linux Lenny - Linux user #188.598
signature.asc
Description: Digital signature
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
Hi, Joseph. On Thursday, 12 August 2010 20:00:29 +, Joseph L. Casale wrote: > >> Indeed, I'm using CentOS 5.5 amd64. I was not doing the > >> installation with RPM packages, but compile the source code > >> obtained at the official site of Bacula. On sunday, doing tests > >> comparing with the installation done with packages RPM, I realized > >> that the difference was in which the libraries were in /usr/lib64. > >You may consider rebuilding a Fedora Rawhide source RPM which is > >supposed to be the latest Bacula source code version, but does > >include the semantics to make it all work properly in the end -on > >most Fedora derivative systems. > I've been following this thread in hopes of uncovering the reason why > the op would even compile himself for a platform that has precompiled > binaries available (lets forgo the obvious argument for destroying a > package managed Cadillac OS in the first place) and I haven't seen it > appear? > Why the need to endure all this pain in the first place? Even if > compile time options needed to be changed, wouldn't it be > easier/smarter/faster/lighter/shinier to modify the spec and rebuild? I'm compiling Bacula because after searching on the official repositories of CentOS 5.5, I did not find precompiled binaries. Luckily I was able to solve this problem, although in the past days I was busy with other things and so I could not continue with this thread. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
>> Indeed, I'm using CentOS 5.5 amd64. I was not doing the installation >> with RPM packages, but compile the source code obtained at the official >> site of Bacula. On sunday, doing tests comparing with the installation >> done with packages RPM, I realized that the difference was in which the >> libraries were in /usr/lib64. >> > >You may consider rebuilding a Fedora Rawhide source RPM which is supposed to >be the latest Bacula source code version, but does include the semantics to >make it all work properly in the end -on most Fedora derivative systems. I've been following this thread in hopes of uncovering the reason why the op would even compile himself for a platform that has precompiled binaries available (lets forgo the obvious argument for destroying a package managed Cadillac OS in the first place) and I haven't seen it appear? Why the need to endure all this pain in the first place? Even if compile time options needed to be changed, wouldn't it be easier/smarter/faster/lighter/shinier to modify the spec and rebuild? -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
Daniel Bareiro wrote: > Indeed, I'm using CentOS 5.5 amd64. I was not doing the installation > with RPM packages, but compile the source code obtained at the official > site of Bacula. On sunday, doing tests comparing with the installation > done with packages RPM, I realized that the difference was in which the > libraries were in /usr/lib64. > You may consider rebuilding a Fedora Rawhide source RPM which is supposed to be the latest Bacula source code version, but does include the semantics to make it all work properly in the end -on most Fedora derivative systems. The maximum level of trouble I've ran into is Build Requirements that have differences in their names between the newer Fedora generation and the older more stable Enterprise Linux realm. > Doing again the configuration using this time the --libdir=/usr/lib64 > parameter, the problem was not reproduced. What it is strange to me is > that in an installation of Debian Lenny amd64, I didn't do the > configuration using --libdir=/usr/lib64 and in spite of putting the > libraries in /usr/lib, I did not have the problem occurred in CentOS. > > What can be the difference? > Probably a very liberal /etc/ld.so.conf on Debian, or something like that. -- Jeroen -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
> On Wed, 11 Aug 2010 01:17:11 -0300, Daniel Bareiro said: > > On Wednesday, 11 August 2010 00:46:06 -0300, > Daniel Bareiro wrote: > > > > It looks like you are running a 64-bit bacula-sd, so the libraries > > > should be in /usr/lib64. > > > > > > The files you found are in /usr/lib, which are normally 32-bit. > > > Either you have the 32-bit libraries installed by accident or the > > > 64-bit libraries are installed in the wrong place (broken rpm?). > > > Indeed, I'm using CentOS 5.5 amd64. I was not doing the installation > > with RPM packages, but compile the source code obtained at the > > official site of Bacula. On sunday, doing tests comparing with the > > installation done with packages RPM, I realized that the difference > > was in which the libraries were in /usr/lib64. > > > > Doing again the configuration using this time the --libdir=/usr/lib64 > > parameter, the problem was not reproduced. What it is strange to me is > > that in an installation of Debian Lenny amd64, I didn't do the > > configuration using --libdir=/usr/lib64 and in spite of putting the > > libraries in /usr/lib, I did not have the problem occurred in CentOS. > > I already found the cause: > > # ll /usr/lib > lib/ lib32/ lib64/ > # ll -d /usr/lib > drwxr-xr-x 41 root root 20480 ago 8 01:56 /usr/lib > # ll -d /usr/lib32 > lrwxrwxrwx 1 root root 24 abr 11 2009 /usr/lib32 -> /emul/ia32-linux/usr/lib > # ll -d /usr/lib64 > lrwxrwxrwx 1 root root 3 abr 11 2009 /usr/lib64 -> lib Yes, 64-bit Debian and 64-bit CentOS use different layouts for the lib directories. __Martin -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
On Wednesday, 11 August 2010 00:46:06 -0300, Daniel Bareiro wrote: > > It looks like you are running a 64-bit bacula-sd, so the libraries > > should be in /usr/lib64. > > > > The files you found are in /usr/lib, which are normally 32-bit. > > Either you have the 32-bit libraries installed by accident or the > > 64-bit libraries are installed in the wrong place (broken rpm?). > Indeed, I'm using CentOS 5.5 amd64. I was not doing the installation > with RPM packages, but compile the source code obtained at the > official site of Bacula. On sunday, doing tests comparing with the > installation done with packages RPM, I realized that the difference > was in which the libraries were in /usr/lib64. > > Doing again the configuration using this time the --libdir=/usr/lib64 > parameter, the problem was not reproduced. What it is strange to me is > that in an installation of Debian Lenny amd64, I didn't do the > configuration using --libdir=/usr/lib64 and in spite of putting the > libraries in /usr/lib, I did not have the problem occurred in CentOS. I already found the cause: # ll /usr/lib lib/ lib32/ lib64/ # ll -d /usr/lib drwxr-xr-x 41 root root 20480 ago 8 01:56 /usr/lib # ll -d /usr/lib32 lrwxrwxrwx 1 root root 24 abr 11 2009 /usr/lib32 -> /emul/ia32-linux/usr/lib # ll -d /usr/lib64 lrwxrwxrwx 1 root root 3 abr 11 2009 /usr/lib64 -> lib It's a smart move :-) Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
Hi, Martin. On Monday, 09 August 2010 13:35:43 +0100, Martin Simmons wrote: > > > what is the output of 'ldd /usr/sbin/bacula-sd' ? > > # ldd /usr/sbin/bacula-sd > > libz.so.1 => /usr/lib64/libz.so.1 (0x0032b900) > > libbacpy-5.0.1.so => not found > > libbaccfg-5.0.1.so => not found > > libbac-5.0.1.so => not found > > libpthread.so.0 => /lib64/libpthread.so.0 (0x0032b840) > > libdl.so.2 => /lib64/libdl.so.2 (0x0032b800) > > libssl.so.6 => /lib64/libssl.so.6 (0x0032bb00) > > libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0032ba80) > > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0032ba00) > > libm.so.6 => /lib64/libm.so.6 (0x0032b880) > > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0032ba40) > > libc.so.6 => /lib64/libc.so.6 (0x0032b7c0) > > /lib64/ld-linux-x86-64.so.2 (0x0032b780) > > libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 > > (0x0032bc40) > > libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0032bdc0) > > libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0032bcc0) > > libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0032bd80) > > libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 > > (0x0032be00) > > libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0032bc80) > > libresolv.so.2 => /lib64/libresolv.so.2 (0x0032bd40) > > libselinux.so.1 => /lib64/libselinux.so.1 (0x0032b940) > > libsepol.so.1 => /lib64/libsepol.so.1 (0x0032b8c0) > > > > > > Apparently, in spite of being the libraries in the operating system, > > for some reason it is not finding them. > It looks like you are running a 64-bit bacula-sd, so the libraries > should be in /usr/lib64. > > The files you found are in /usr/lib, which are normally 32-bit. > Either you have the 32-bit libraries installed by accident or the > 64-bit libraries are installed in the wrong place (broken rpm?). Indeed, I'm using CentOS 5.5 amd64. I was not doing the installation with RPM packages, but compile the source code obtained at the official site of Bacula. On sunday, doing tests comparing with the installation done with packages RPM, I realized that the difference was in which the libraries were in /usr/lib64. Doing again the configuration using this time the --libdir=/usr/lib64 parameter, the problem was not reproduced. What it is strange to me is that in an installation of Debian Lenny amd64, I didn't do the configuration using --libdir=/usr/lib64 and in spite of putting the libraries in /usr/lib, I did not have the problem occurred in CentOS. What can be the difference? Thanks for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
> On Sun, 8 Aug 2010 18:03:41 -0300, Daniel Bareiro said: > > On Thursday, 29 July 2010 09:19:50 +0200, > Pierre Bourgin wrote: > > > Hello, > > Hi, Pierre. > > But when trying to run the startup script, I get the following > errors: > > [r...@localhost scripts]# /etc/init.d/bacula start > Starting the Bacula Storage daemon /usr/sbin/bacula-sd: error while > loading shared libraries: > libbacpy-5.0.1.so: cannot open shared object file: No such file or > directory > Starting the Bacula File daemon /usr/sbin/bacula-fd: error while loading > shared libraries: > libbacfind-5.0.1.so: cannot open shared object file: No such file or > directory > Starting the Bacula Director daemon /usr/sbin/bacula-dir: error while > loading shared libraries: > libbacfind-5.0.1.so: cannot open shared object file: No such file or > directory > > But the files are: > > [r...@localhost scripts]# ll /usr/lib/libbacpy-5.0.1.so > -rwxr-xr-- 1 root root 24083 jul 22 12:25 /usr/lib/libbacpy-5.0.1.so > > [r...@localhost scripts]# ll /usr/lib/libbacfind-5.0.1.so > -rwxr-xr-- 1 root root 228325 jul 22 12:25 /usr/lib/libbacfind-5.0.1.so > > >>> Have you ran ldconfig? It generates the "available libraries" cache for > >>> the > >>> dynamic linker, and the dynamic linker is relatively strict about not > >>> searching various locations throughout the filesystem. > >>> > >>> You can verify dynamic linking capabilities with "ldd /path/to/binary". > >>> > >>> Also, you may want to consider Security Enhanced Linux. Verify with the > >>> "sestatus" command whether SELinux is enforcing the targeted policy, and > >>> if > >>> so, consider restoring the default context for the files freshly installed > >>> using restorecon, and if all else fails, please get back to us with ls -Z > >>> output ;-) > > >> I was also trying to install Bacula 5.0.1 using the same procedure as > >> mentioned in previous email and I have the same problem. This procedure > >> was successful in Debian with the difference that there I updated a > >> previous version instead of installing from scratch. > >> > >> Like I said, I followed the steps mentioned in the other email (I did > >> not run ldconfig manually) that had been successful in Debian. Using ldd > >> with these two libraries, I get the following: > >> > >> [r...@localhost init.d]# ldd /usr/lib/libbacpy-5.0.1.so > >> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x2b4eb5ee7000) > >> libm.so.6 => /lib64/libm.so.6 (0x2b4eb61e7000) > >> libc.so.6 => /lib64/libc.so.6 (0x2b4eb646a000) > >> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b4eb67c2000) > >> /lib64/ld-linux-x86-64.so.2 (0x00320a40) > >> > >> [r...@localhost init.d]# ldd /usr/lib/libbacfind-5.0.1.so > >> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x2b97a2131000) > >> libm.so.6 => /lib64/libm.so.6 (0x2b97a2431000) > >> libc.so.6 => /lib64/libc.so.6 (0x2b97a26b4000) > >> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b97a2a0c000) > >> /lib64/ld-linux-x86-64.so.2 (0x00320a40) > > > what is the output of 'ldd /usr/sbin/bacula-sd' ? > > # ldd /usr/sbin/bacula-sd > libz.so.1 => /usr/lib64/libz.so.1 (0x0032b900) > libbacpy-5.0.1.so => not found > libbaccfg-5.0.1.so => not found > libbac-5.0.1.so => not found > libpthread.so.0 => /lib64/libpthread.so.0 (0x0032b840) > libdl.so.2 => /lib64/libdl.so.2 (0x0032b800) > libssl.so.6 => /lib64/libssl.so.6 (0x0032bb00) > libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0032ba80) > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0032ba00) > libm.so.6 => /lib64/libm.so.6 (0x0032b880) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0032ba40) > libc.so.6 => /lib64/libc.so.6 (0x0032b7c0) > /lib64/ld-linux-x86-64.so.2 (0x0032b780) > libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 > (0x0032bc40) > libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0032bdc0) > libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0032bcc0) > libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0032bd80) > libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 > (0x0032be00) > libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0032bc80) > libresolv.so.2 => /lib64/libresolv.so.2 (0x0032bd40) > libselinux.so.1 => /lib64/libselinux.so.1 (0x0032b940) > libsepol.so.1 => /lib64/libsepol.so.1 (0x0032b8c0) > > > Apparently, in spite of being the libraries in the operating system, for > some reason it is not finding them. It looks like you are running a 64-bit bacula-sd, so the libraries should b
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
On Thursday, 29 July 2010 09:19:50 +0200, Pierre Bourgin wrote: > Hello, Hi, Pierre. But when trying to run the startup script, I get the following errors: [r...@localhost scripts]# /etc/init.d/bacula start Starting the Bacula Storage daemon /usr/sbin/bacula-sd: error while loading shared libraries: libbacpy-5.0.1.so: cannot open shared object file: No such file or directory Starting the Bacula File daemon /usr/sbin/bacula-fd: error while loading shared libraries: libbacfind-5.0.1.so: cannot open shared object file: No such file or directory Starting the Bacula Director daemon /usr/sbin/bacula-dir: error while loading shared libraries: libbacfind-5.0.1.so: cannot open shared object file: No such file or directory But the files are: [r...@localhost scripts]# ll /usr/lib/libbacpy-5.0.1.so -rwxr-xr-- 1 root root 24083 jul 22 12:25 /usr/lib/libbacpy-5.0.1.so [r...@localhost scripts]# ll /usr/lib/libbacfind-5.0.1.so -rwxr-xr-- 1 root root 228325 jul 22 12:25 /usr/lib/libbacfind-5.0.1.so >>> Have you ran ldconfig? It generates the "available libraries" cache for the >>> dynamic linker, and the dynamic linker is relatively strict about not >>> searching various locations throughout the filesystem. >>> >>> You can verify dynamic linking capabilities with "ldd /path/to/binary". >>> >>> Also, you may want to consider Security Enhanced Linux. Verify with the >>> "sestatus" command whether SELinux is enforcing the targeted policy, and if >>> so, consider restoring the default context for the files freshly installed >>> using restorecon, and if all else fails, please get back to us with ls -Z >>> output ;-) >> I was also trying to install Bacula 5.0.1 using the same procedure as >> mentioned in previous email and I have the same problem. This procedure >> was successful in Debian with the difference that there I updated a >> previous version instead of installing from scratch. >> >> Like I said, I followed the steps mentioned in the other email (I did >> not run ldconfig manually) that had been successful in Debian. Using ldd >> with these two libraries, I get the following: >> >> [r...@localhost init.d]# ldd /usr/lib/libbacpy-5.0.1.so >> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x2b4eb5ee7000) >> libm.so.6 => /lib64/libm.so.6 (0x2b4eb61e7000) >> libc.so.6 => /lib64/libc.so.6 (0x2b4eb646a000) >> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b4eb67c2000) >> /lib64/ld-linux-x86-64.so.2 (0x00320a40) >> >> [r...@localhost init.d]# ldd /usr/lib/libbacfind-5.0.1.so >> libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x2b97a2131000) >> libm.so.6 => /lib64/libm.so.6 (0x2b97a2431000) >> libc.so.6 => /lib64/libc.so.6 (0x2b97a26b4000) >> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b97a2a0c000) >> /lib64/ld-linux-x86-64.so.2 (0x00320a40) > what is the output of 'ldd /usr/sbin/bacula-sd' ? # ldd /usr/sbin/bacula-sd libz.so.1 => /usr/lib64/libz.so.1 (0x0032b900) libbacpy-5.0.1.so => not found libbaccfg-5.0.1.so => not found libbac-5.0.1.so => not found libpthread.so.0 => /lib64/libpthread.so.0 (0x0032b840) libdl.so.2 => /lib64/libdl.so.2 (0x0032b800) libssl.so.6 => /lib64/libssl.so.6 (0x0032bb00) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0032ba80) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0032ba00) libm.so.6 => /lib64/libm.so.6 (0x0032b880) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0032ba40) libc.so.6 => /lib64/libc.so.6 (0x0032b7c0) /lib64/ld-linux-x86-64.so.2 (0x0032b780) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0032bc40) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0032bdc0) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0032bcc0) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0032bd80) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0032be00) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0032bc80) libresolv.so.2 => /lib64/libresolv.so.2 (0x0032bd40) libselinux.so.1 => /lib64/libselinux.so.1 (0x0032b940) libsepol.so.1 => /lib64/libsepol.so.1 (0x0032b8c0) Apparently, in spite of being the libraries in the operating system, for some reason it is not finding them. Thanks for your reply. Regards, Daniel -- Daniel Bareiro - GNU/Linux registered user #188.598 Proudly running Debian GNU/Linux with uptime: 17:52:49 up 29 days, 22:45, 11 users, load average: 0.05, 0.03, 0.01 signature.asc Description: Digital signature -- This SF.net
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
Hello, On 07/23/2010 11:52 AM, Daniel Bareiro wrote: > On Friday, 23 July 2010 02:13:51 +0200, > Jeroen van Meeuwen wrote: > >> Hi there Daniel! > > Hi, Jeroen! > >>> But when trying to run the startup script, I get the following >>> errors: >>> >>> [r...@localhost scripts]# /etc/init.d/bacula start >>> Starting the Bacula Storage daemon /usr/sbin/bacula-sd: error while loading >>> shared libraries: >>> libbacpy-5.0.1.so: cannot open shared object file: No such file or directory >>> Starting the Bacula File daemon /usr/sbin/bacula-fd: error while loading >>> shared libraries: >>> libbacfind-5.0.1.so: cannot open shared object file: No such file or >>> directory >>> Starting the Bacula Director daemon /usr/sbin/bacula-dir: error while >>> loading shared libraries: >>> libbacfind-5.0.1.so: cannot open shared object file: No such file or >>> directory >>> >>> But the files are: >>> >>> [r...@localhost scripts]# ll /usr/lib/libbacpy-5.0.1.so >>> -rwxr-xr-- 1 root root 24083 jul 22 12:25 /usr/lib/libbacpy-5.0.1.so >>> >>> [r...@localhost scripts]# ll /usr/lib/libbacfind-5.0.1.so >>> -rwxr-xr-- 1 root root 228325 jul 22 12:25 /usr/lib/libbacfind-5.0.1.so > >> Have you ran ldconfig? It generates the "available libraries" cache for the >> dynamic linker, and the dynamic linker is relatively strict about not >> searching various locations throughout the filesystem. >> >> You can verify dynamic linking capabilities with "ldd /path/to/binary". >> >> Also, you may want to consider Security Enhanced Linux. Verify with the >> "sestatus" command whether SELinux is enforcing the targeted policy, and if >> so, consider restoring the default context for the files freshly installed >> using restorecon, and if all else fails, please get back to us with ls -Z >> output ;-) > > I was also trying to install Bacula 5.0.1 using the same procedure as > mentioned in previous email and I have the same problem. This procedure > was successful in Debian with the difference that there I updated a > previous version instead of installing from scratch. > > Like I said, I followed the steps mentioned in the other email (I did > not run ldconfig manually) that had been successful in Debian. Using ldd > with these two libraries, I get the following: > > [r...@localhost init.d]# ldd /usr/lib/libbacpy-5.0.1.so > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x2b4eb5ee7000) > libm.so.6 => /lib64/libm.so.6 (0x2b4eb61e7000) > libc.so.6 => /lib64/libc.so.6 (0x2b4eb646a000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b4eb67c2000) > /lib64/ld-linux-x86-64.so.2 (0x00320a40) > > [r...@localhost init.d]# ldd /usr/lib/libbacfind-5.0.1.so > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x2b97a2131000) > libm.so.6 => /lib64/libm.so.6 (0x2b97a2431000) > libc.so.6 => /lib64/libc.so.6 (0x2b97a26b4000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b97a2a0c000) > /lib64/ld-linux-x86-64.so.2 (0x00320a40) what is the output of 'ldd /usr/sbin/bacula-sd' ? > > Comparing this output with the one I get with the same version of Bacula > (5.0.1) installed with the same procedure in Debian, I'm seeing that in > both files are additionally a reference to linux-vdso.so.1. > > Can this be the cause of the problem? > > > Thanks for your reply. > > Regards, > Daniel -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
On Friday, 23 July 2010 02:13:51 +0200, Jeroen van Meeuwen wrote: > Hi there Daniel! Hi, Jeroen! > > But when trying to run the startup script, I get the following > > errors: > > > > [r...@localhost scripts]# /etc/init.d/bacula start > > Starting the Bacula Storage daemon /usr/sbin/bacula-sd: error while loading > > shared libraries: > > libbacpy-5.0.1.so: cannot open shared object file: No such file or directory > > Starting the Bacula File daemon /usr/sbin/bacula-fd: error while loading > > shared libraries: > > libbacfind-5.0.1.so: cannot open shared object file: No such file or > > directory > > Starting the Bacula Director daemon /usr/sbin/bacula-dir: error while > > loading shared libraries: > > libbacfind-5.0.1.so: cannot open shared object file: No such file or > > directory > > > > But the files are: > > > > [r...@localhost scripts]# ll /usr/lib/libbacpy-5.0.1.so > > -rwxr-xr-- 1 root root 24083 jul 22 12:25 /usr/lib/libbacpy-5.0.1.so > > > > [r...@localhost scripts]# ll /usr/lib/libbacfind-5.0.1.so > > -rwxr-xr-- 1 root root 228325 jul 22 12:25 /usr/lib/libbacfind-5.0.1.so > Have you ran ldconfig? It generates the "available libraries" cache for the > dynamic linker, and the dynamic linker is relatively strict about not > searching various locations throughout the filesystem. > > You can verify dynamic linking capabilities with "ldd /path/to/binary". > > Also, you may want to consider Security Enhanced Linux. Verify with the > "sestatus" command whether SELinux is enforcing the targeted policy, and if > so, consider restoring the default context for the files freshly installed > using restorecon, and if all else fails, please get back to us with ls -Z > output ;-) I was also trying to install Bacula 5.0.1 using the same procedure as mentioned in previous email and I have the same problem. This procedure was successful in Debian with the difference that there I updated a previous version instead of installing from scratch. Like I said, I followed the steps mentioned in the other email (I did not run ldconfig manually) that had been successful in Debian. Using ldd with these two libraries, I get the following: [r...@localhost init.d]# ldd /usr/lib/libbacpy-5.0.1.so libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x2b4eb5ee7000) libm.so.6 => /lib64/libm.so.6 (0x2b4eb61e7000) libc.so.6 => /lib64/libc.so.6 (0x2b4eb646a000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b4eb67c2000) /lib64/ld-linux-x86-64.so.2 (0x00320a40) [r...@localhost init.d]# ldd /usr/lib/libbacfind-5.0.1.so libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x2b97a2131000) libm.so.6 => /lib64/libm.so.6 (0x2b97a2431000) libc.so.6 => /lib64/libc.so.6 (0x2b97a26b4000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x2b97a2a0c000) /lib64/ld-linux-x86-64.so.2 (0x00320a40) Comparing this output with the one I get with the same version of Bacula (5.0.1) installed with the same procedure in Debian, I'm seeing that in both files are additionally a reference to linux-vdso.so.1. Can this be the cause of the problem? Thanks for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
Daniel Bareiro wrote: > Hi all! > Hi there Daniel! > But when trying to run the startup script, I get the following errors: > > [r...@localhost scripts]# /etc/init.d/bacula start > Starting the Bacula Storage daemon /usr/sbin/bacula-sd: error while loading shared libraries: > libbacpy-5.0.1.so: cannot open shared object file: No such file or directory > Starting the Bacula File daemon /usr/sbin/bacula-fd: error while loading shared libraries: > libbacfind-5.0.1.so: cannot open shared object file: No such file or directory > Starting the Bacula Director daemon /usr/sbin/bacula-dir: error while loading shared libraries: > libbacfind-5.0.1.so: cannot open shared object file: No such file or directory > > But the files are: > > [r...@localhost scripts]# ll /usr/lib/libbacpy-5.0.1.so > -rwxr-xr-- 1 root root 24083 jul 22 12:25 /usr/lib/libbacpy-5.0.1.so > > [r...@localhost scripts]# ll /usr/lib/libbacfind-5.0.1.so > -rwxr-xr-- 1 root root 228325 jul 22 12:25 /usr/lib/libbacfind-5.0.1.so > Have you ran ldconfig? It generates the "available libraries" cache for the dynamic linker, and the dynamic linker is relatively strict about not searching various locations throughout the filesystem. You can verify dynamic linking capabilities with "ldd /path/to/binary". Also, you may want to consider Security Enhanced Linux. Verify with the "sestatus" command whether SELinux is enforcing the targeted policy, and if so, consider restoring the default context for the files freshly installed using restorecon, and if all else fails, please get back to us with ls -Z output ;-) -- Jeroen -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Installing Bacula on Red Hat Enterprise Linux Server 5.5 (Tikanga)
Hi all! I'm installing Bacula 5.0.2 on RHEL 5.5 using the following procedure after having downloaded the bacula-5.0.2.tar.gz tarball: # ./configure \ --prefix=/usr \ --sbindir=/usr/sbin \ --sysconfdir=/etc/bacula \ --with-scriptdir=/etc/bacula/scripts \ --enable-smartalloc \ --with-openssl \ --with-mysql \ --with-working-dir=/var/lib/bacula \ --with-pid-dir=/var/run \ --with-subsys-dir=/var/lock \ --with-dir-user=bacula \ --with-dir-group=bacula \ --with-sd-user=bacula \ --with-sd-group=bacula \ --with-fd-user=root # make -j6 # make install # cp -a /etc/bacula/bacula /etc/init.d/ # /usr/sbin/groupadd -g 90 bacula # /usr/sbin/useradd -c "Bacula" -d /var/lib/bacula -m -k /dev/null -g bacula -u 90 -s /bin/bash bacula /etc/bacula/scripts# ./grant_mysql_privileges /etc/bacula/scripts# ./create_mysql_database /etc/bacula/scripts# ./make_mysql_tables But when trying to run the startup script, I get the following errors: [r...@localhost scripts]# /etc/init.d/bacula start Starting the Bacula Storage daemon /usr/sbin/bacula-sd: error while loading shared libraries: libbacpy-5.0.1.so: cannot open shared object file: No such file or directory Starting the Bacula File daemon /usr/sbin/bacula-fd: error while loading shared libraries: libbacfind-5.0.1.so: cannot open shared object file: No such file or directory Starting the Bacula Director daemon /usr/sbin/bacula-dir: error while loading shared libraries: libbacfind-5.0.1.so: cannot open shared object file: No such file or directory But the files are: [r...@localhost scripts]# ll /usr/lib/libbacpy-5.0.1.so -rwxr-xr-- 1 root root 24083 jul 22 12:25 /usr/lib/libbacpy-5.0.1.so [r...@localhost scripts]# ll /usr/lib/libbacfind-5.0.1.so -rwxr-xr-- 1 root root 228325 jul 22 12:25 /usr/lib/libbacfind-5.0.1.so It is some permissions problem perhaps? One of the differences I found that I have with an installation of Bacula 5.0.1 is that both the 'scripts' directory and the files inside of it are with user and group bacula:bacula. I changed these permissions because they were with root:root, but I still have this problem. Thanks in advance for your reply. Regards, Daniel -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598 signature.asc Description: Digital signature -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
