Dan, Bacula-users,
The problem reported below turned out to be a system configuration
issue, not a bacula issue. However, there may be an opportunity for
improved logging and/or diagnostics here. I'm impressed with the fast
response of the list though! Just in case this comes up for someone
else, I'm including the answers to Dan's questions (and the solution to
my problem, correctly specifying access in /etc/hosts.allow) inline:
Dan Langille wrote:
On 18 Sep 2005 at 22:29, Josh Homan wrote:
I'm having a problem getting Bacula 1.36.3 to work on my FreeBSD
5.4 system. I've installed both /usr/ports/sysutils/bacula-server
and /usr/ports/sysutils/bacula-client on the machine, created a
MySQL database and user, populated the tables, and customized the
bconsole.conf file to include the same password as the
bacula-dir.conf file, and then fired bacula up by running
/usr/local/etc/rc.d/z-bacula.sh.sample start. I then run the
bconsole program, and immediately get back:
# bconsole -c /usr/local/etc/bconsole.conf Connecting to Director
192.168.123.80:9101 18-Sep 21:58 bconsole: Fatal error: bnet.c:209
Packet size too big from "Director daemon:192.168.123.80:9101.
Terminating connection. Director authorization problem. Most likely
the passwords do not agree. Please see
http://www.bacula.org/html-manual/faq.html#AuthorizationErrors for
help. ERR=
"immediately" tells me that bacula-dir is actually running.
Correct. Verified several ways, including ps listings.
Is it running at 192.168.123.80?
Yes. sockstat showed that it was binding to all addresses. And I get a
different message back from bconsole if bacula-dir isn't running.
Anything in log files? /var/log/messages ?
As stated, the only error message I found (because I hadn't looked hard
enough) was the error message from bconsole which was logged in
/var/log/messages. I did not, before posting to the list, look in
/var/log/auth.log.
Is this a /etc/hosts.allow issue?
In fact, YES! It turned out to be an issue with /etc/hosts.allow -- I
had neglected to allow any network access to bacula -- my default line
in /etc/hosts.allow twists connections that I haven't explicitly
allowed, reporting the message "You are not welcome to use %d from %h."
I am sure the password and name of the director are correctly
specified in bconsole.conf and bacula-dir.conf.
Prove it. Paste it to us.
Since the problem has been solved, I'll skip this, but I did in fact cut
the relevant lines out of the conf files and pasted them into separate
files, and then diff'ed the result to prove to myself that they were the
same.
When I try to run the director in the foreground with the debug
level kicked up, here's what I get:
# /usr/local/sbin/bacula-dir -f -d99 -u bacula -g bacula -v -c
/usr/local/etc/bacula-dir.conf bacula-dir: dird.c:131 Debug level =
99 bacula-dir: mysql.c:141 mysql_init done bacula-dir: mysql.c:161
mysql_real_connect done bacula-dir: mysql.c:163 db_user=bacula
db_name=bacula db_password=xxxxx
Then, nothing from the director until I try and connect from
bconsole, at which point it just drops me back to my prompt. No
mail is sent to root@, only the bconsole error is logged in my
syslog, and no log file is created, so I'm sort of puzzled with
where to go next.
So the Director stops running?
Yes, which was pretty curious to me. I even bumped the debug level up to
2000(!!), and there was _no_ message from the director, it just stopped
running and silently dropped me back to a root prompt. I did finally get
around to looking at auth.log (actually I was looking at it for reasons
other than bacula) about an hour after I posted to the list, and there
was the message I was looking for:
Sep 19 01:51:37 <myhost> bacula-fd: twist <myhost> to /bin/echo "You are
not welcome to use <mydir> from <myhost>."
As a test, I dropped an ALL : <mynet> : allow, and bacula is now working
as expected. After some trial and error, I found that the hosts.allow
listing needed to be the name of the particular bacula service, so for
me it turned out to be <myhost>-dir, <myhost>-sd, and <myhost>-fd. While
this seems counter-intuitive to me (the log messages and the
hosts_access manpage led me to believe that specifying the daemon names,
like bacula-dir, bacula-sd, and bacula-fd would be appropriate), I can
see how it provides for much better flexibility.
So after all this, I just found the bacula security issues web page, and
all of this information is actually clearly documented:
http://www.bacula.org/rel-manual/Bacula_Security_Issues.html
Thanks again for the quick assistance!
Regards,
Josh
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users