Re: [Bacula-users] Building bacula on OpenBSD

[GUILLON G. <gab...@c-...>]

This link:
http://people.collaborativefusion.com/~seklecki/bacula_openbsd_port.tar

seems to be broken

Brian A. Seklecki a =E9crit :
>=20
> Here is a functional FD on OpenBSD 4.0/i386:
>=20
> bash-3.2# uname -a
> OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0
> GENERIC.MP+RAIDFRAME#1
>=20
> bash-3.2# /usr/local/sbin/bacula-fd -u root -g wheel  -d128 -v -c
> /usr/local/etc/bacula-fd.conf -f
> vmware-sandbox-fd: jcr.c:129 read_last_jobs seek to 188
> vmware-sandbox-fd: jcr.c:136 Read num_items=3D0
> vmware-sandbox-fd: filed.c:223 filed: listening on port 9102
> vmware-sandbox-fd: bnet_server.c:98 Addresses host[ipv4:0.0.0.0:9102]
> vmware-sandbox-fd: bnet.c:1154 who=3Dclient host=3D192.168.4.55 port=3D=
36387
> vmware-sandbox-fd: find.c:81 init_find_files ff=3D-7e0f0be8
> vmware-sandbox-fd: job.c:216 <dird: Hello Director mindwipe-dir calling
> vmware-sandbox-fd: job.c:232 Executing Hello command.
> vmware-sandbox-fd: job.c:337 Calling Authenticate
> vmware-sandbox-fd: cram-md5.c:71 send: auth cram-md5
> <1231743667.1163339252@vmware-sandbox-fd> ssl=3D0
> vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5
> <2026280212.1166033378@mindwipe-dir> ssl=3D0
> vmware-sandbox-fd: cram-md5.c:150 sending resp to challenge:
> TS/yz8d8e9BM/gxwO9++iC
> vmware-sandbox-fd: job.c:341 OK Authenticate
> vmware-sandbox-fd: job.c:216 <dird: JobId=3D0
> Job=3D*Console*.2006-12-13_13.09.33 SDid=3D0 SDtime=3D0 Authorization=3D=
dummy
> vmware-sandbox-fd: job.c:232 Executing JobId=3D command.
> vmware-sandbox-fd: job.c:435 JobId=3D0 Auth=3Ddummy
> vmware-sandbox-fd: job.c:216 <dird: statusvmware-sandbox-fd: job.c:232
> Executing status command.
> vmware-sandbox-fd: job.c:322 Calling term_find_files
> vmware-sandbox-fd: job.c:325 Done with term_find_files
> vmware-sandbox-fd: job.c:327 Done with free_jcr
>=20
> The code for this may be found at:
>=20
> http://people.collaborativefusion.com/~seklecki/obsd_bacula.html
>=20
> This illustrates basic support.
>=20
> I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to
> have made it through:
>=20
> bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066:
> to=3D<gn...@op...>,
> ctladdr=3D<sek...@vm...>
> (1016/10), delay=3D00:00:16, xdelay=3D00:00:16, mailer=3Desmtp, pri=3D3=
1100,
> relay=3Dcvs.openbsd.org. [199.185.137.3], dsn=3D4.3.0, stat=3DDeferred:=
 451
> Temporary failure, please try again later.
>=20
> Possibly greylisting....~
>=20
> ~BAS
>=20
>=20
> On Wed, 13 Dec 2006, Brian A. Seklecki wrote:
>=20
>>>> Stop in /usr/local/src/bacula-1.38.11/src/stored.
>>>
>>> It looks to me like the OS' header file is badly broken -- at least
>>> in the
>>> sense that if it is a Unix system, both mt_fileno and mt_blkno should=
 be
>>> defined in the struct mtget.
>>>
>>> Someone should fix the OS, barring that we will need a patch.
>>
>> Kern, Rus, et al:
>>
>> We have to be really careful with regard how we word things here.  The
>> way you assert that could be easily misinterpreted or misconstrued to
>> have a vendor-bashing tone.
>>
>> Moreover, conceding the unavailability of compatibility with the OpenB=
SD
>> platform doesn't gain us any additional users; a very large group of
>> talented individuals with tremendous experience writing highly secure,
>> reliable, and _portable_ code who could contribute greatly to the
>> project.
>>
>> -- To set the record straight, and encourage mutual cooperation --
>>
>> The reality here is that OpenBSD is very selective about where it
>> focuses its development efforts, and the st(4) driver is not one of
>> those places.
>>
>> Therefore, the assertion that "The OS is broken" is not correct, it
>> simply hasn't been implemented or maintained as it should.
>>
>> Before I go on and make my own silly assertions, I should note: '
>>
>>   Things are always subject to change, and this is F/OSS and you're
>>   always welcome to do the work yourself or have corporate sponsorship=
.
>>
>> OpenBSD is not the platform for a Bacula director.  You wont see it (a=
t
>> present) driving a 5-LTO3-drive, 2000 tape, 1000+ Terabyte StorageTek
>> Powderhorn Tape Silo connected via Brocade FC switches.(1)
>>
>> However you will see it at the perimeter and on the wire keeping the
>> packet kiddies from stealing all of your customers data.  It could be
>> the ideal system for the job with features like enhanced crypto
>> acceleration via crypto(9) and the existing improvements on scsi(4) an=
d
>> recent HBA support.
>>
>> Anyway, not a director, not now at least, and probably not a SD Storag=
e
>> Daemon either.
>>
>> But most definitely a management console and file daemon.
>>
>> Russel: You'll probably notice that Bacula builds perfectly fine up
>> until it gets to the director, then you get into OS-specific kernel
>> knits and hooks where either OpenBSD lacks the framework/API (pthreads=
,
>> st(4), etc.) or kernel-specific code needs to be added to Bacula.
>>
>> In the mean time, we should endeavor to create a "bacula-clientonly"
>> Port in OpenBSD ports, or "bacula" port with a "clientonly" flavor.
>>
>> This has been done before, but the work was never commited (CC:)
>>
>> 1. http://www.arsc.edu/resources/silo.html
>>
>> I will take the lead on this if I have to.
>>
>> ~BAS
>>
>>>
>>> I checked the man page for st, where all other Unix systems define
>>> the packet.
>>> They include no definition, so you will need to consult the header fi=
le
>>> directly sys/mtio.h.   Sorry, but you are pretty much on your own on
>>> this.
>>>
>>>
>>>
>>>>
>>>>
>>>>   =3D=3D=3D=3D=3D=3D Error in /usr/local/src/bacula-1.38.11/src/stor=
ed =3D=3D=3D=3D=3D=3D
>>>>
>>>>
>>>> =3D=3D>Entering directory /usr/local/src/bacula-1.38.11/src/tools
>>>> =3D=3D=3D=3D Make of tools is good =3D=3D=3D=3D
>>>>
>>
>>
>>
>=20
> l8*
>     -lava (Brian A. Seklecki - Pittsburgh, PA, USA)
>            http://www.spiritual-machines.org/
>=20
> "...from back in the heady days when "helpdesk" meant nothing, "diskquo=
ta"
> meant everything, and lives could be bought and sold for a couple of pa=
ges
> of laser printout - and frequently were."
>=20

--=20
Gabriel Guillon