Re: [Bacula-users] Building bacula on OpenBSD
It looks like some significant improvements have been made to st(4): http://www.openbsd.org/plus41.html Make the st(4) SCSI Tape midlayer return values when receiving a MTIOCGET ioctl, allows things like Bacula to work much http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/st.c Thank you for all who contributed to that. Should we return attention to getting a comprehensive Bacula port committed? ~BAS On Fri, 2006-12-22 at 19:09 +0100, Kern Sibbald wrote: On Sunday 17 December 2006 18:45, Kenneth Westerback wrote: Thanks for bringing this discussion to my attention Russell. If someone can point me at the standard or other justification a 'Unix' system requiring mt_blkno and mt_fileno in the mtget structure I'd be more than happy to put them back. I would be even happier if someone could direct me to a discussion on what the mandated or recommended action is for these fields when the OS cannot supply any meaningful information. I note that HPUX seems to always put -1 in them. Well, the best justification for a Unix standard would be Posix, but unfortunately Posix (at least my somewhat old Posix book) does not talk about tape operations. However, FreeBSD, Linux, and Solaris all support MTIOCGET with the mt_fileno and mt_blkno fields in the packet. On some OS the values returned may not be valid, or may not be valid under certain circumstances (e.g. backspace record or backspace file or space to end of medium). Bacula's tape driver references both mt_fileno and mt_blkno and thus if they do not exist, the Storage daemon (tape driver part will not compile). However, the user can configure his Bacula driver (in bacula-sd.conf) to essentially not do or ignore the values returned from MTIOCGET. Doing so makes tape operations painfully slow because Bacula must simulate what the kernel SCSI driver can do much more efficiently. Setting mt_fileno and mt_blkno to -1 indicates to any tape I/O aware program such as Bacula that the value is unknown to the SCSI driver, and the program must take appropriate action ... as a consequence, I would see no great harm in defining those fields and always returning -1 in them. Doing so, would probably also permit additional Open Source to compile and run on OpenBSD without specific OpenBSD #ifdefing. Whatever the case may be, the Bacula tape driver already has a lot of #ifdefing in it to adapt to different systems, so I wouldn't be very inclined to #ifdef it so that it does not reference mt_fileno and mt_blkno unless there were several systems that needed such a change. Ken Kenneth R Westerback Technology Architect, Corporate Resources St. Michael's Hospital 30 Bond Street Toronto, Ontario M5B 1W8 Office: 416-864-5981 e-Mail: [EMAIL PROTECTED] www.stmichaelshospital.com This message may contain privileged and confidential information and is intended solely for the use of the intended recipient. If you are neither the intended recipient nor the employee or agent responsible for delivering this communication to the intended recipient, you are hereby notified that any disclosure, copying or distribution of, or the taking of any action in reliance on the contents of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-Mail at [EMAIL PROTECTED] or telephone at 416-864-5981. Thank you. Russell Sutherland [EMAIL PROTECTED] 12/16/06 9:38 AM Here's a note that I received from Ken Westerback, some weeks ago and his take on why these two variables were removed from the include file: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/mtio.h It would appear I removed them since they are not implemented, as of r1.7. I think leaving them in but unimplemented is just misleading. Software that does not function in the absence of this information will be more readily identified if it can't compile. :-). I guess you can add them back to get the compile working, or patch bacula to not touch them. If you have some strong reasons for adding them back to the standard system I'm willing to listen. Ken Kenneth R Westerback Technology Architect, Corporate Resources St. Michael's Hospital 30 Bond Street Toronto, Ontario M5B 1W8 Office: 416-864-5981 e-Mail: [EMAIL PROTECTED] www.stmichaelshospital.com On 13/12/06, Kern Sibbald [EMAIL PROTECTED] wrote: Hello, Since this is directed to me, and assuming I wrote the double 'ed sections below (which sound a lot like me but so much is snipped that I cannot be sure), I can assure you that, my intention, if I am the guity party was not to insult any person or any particular OS, but just to point out that it appears to me to be an OS compatibility problem (actually a system header file to be more correct). See notes below, where I
Re: [Bacula-users] Building bacula on OpenBSD
Well, tape performance will still suck, but a proper port would be another motivating factor for fixing that too. :-). Ken - Original Message From: Brian A. Seklecki [EMAIL PROTECTED] To: Kern Sibbald [EMAIL PROTECTED]; Kenneth Westerback [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ports@openbsd.org; bacula-users@lists.sourceforge.net Sent: Tuesday, April 10, 2007 3:52:10 PM Subject: Re: [Bacula-users] Building bacula on OpenBSD It looks like some significant improvements have been made to st(4): http://www.openbsd.org/plus41.html Make the st(4) SCSI Tape midlayer return values when receiving a MTIOCGET ioctl, allows things like Bacula to work much http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/st.c Thank you for all who contributed to that. Should we return attention to getting a comprehensive Bacula port committed? ~BAS On Fri, 2006-12-22 at 19:09 +0100, Kern Sibbald wrote: On Sunday 17 December 2006 18:45, Kenneth Westerback wrote: Thanks for bringing this discussion to my attention Russell. If someone can point me at the standard or other justification a 'Unix' system requiring mt_blkno and mt_fileno in the mtget structure I'd be more than happy to put them back. I would be even happier if someone could direct me to a discussion on what the mandated or recommended action is for these fields when the OS cannot supply any meaningful information. I note that HPUX seems to always put -1 in them. Well, the best justification for a Unix standard would be Posix, but unfortunately Posix (at least my somewhat old Posix book) does not talk about tape operations. However, FreeBSD, Linux, and Solaris all support MTIOCGET with the mt_fileno and mt_blkno fields in the packet. On some OS the values returned may not be valid, or may not be valid under certain circumstances (e.g. backspace record or backspace file or space to end of medium). Bacula's tape driver references both mt_fileno and mt_blkno and thus if they do not exist, the Storage daemon (tape driver part will not compile). However, the user can configure his Bacula driver (in bacula-sd.conf) to essentially not do or ignore the values returned from MTIOCGET. Doing so makes tape operations painfully slow because Bacula must simulate what the kernel SCSI driver can do much more efficiently. Setting mt_fileno and mt_blkno to -1 indicates to any tape I/O aware program such as Bacula that the value is unknown to the SCSI driver, and the program must take appropriate action ... as a consequence, I would see no great harm in defining those fields and always returning -1 in them. Doing so, would probably also permit additional Open Source to compile and run on OpenBSD without specific OpenBSD #ifdefing. Whatever the case may be, the Bacula tape driver already has a lot of #ifdefing in it to adapt to different systems, so I wouldn't be very inclined to #ifdef it so that it does not reference mt_fileno and mt_blkno unless there were several systems that needed such a change. Ken Kenneth R Westerback Technology Architect, Corporate Resources St. Michael's Hospital 30 Bond Street Toronto, Ontario M5B 1W8 Office: 416-864-5981 e-Mail: [EMAIL PROTECTED] www.stmichaelshospital.com This message may contain privileged and confidential information and is intended solely for the use of the intended recipient. If you are neither the intended recipient nor the employee or agent responsible for delivering this communication to the intended recipient, you are hereby notified that any disclosure, copying or distribution of, or the taking of any action in reliance on the contents of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-Mail at [EMAIL PROTECTED] or telephone at 416-864-5981. Thank you. Russell Sutherland [EMAIL PROTECTED] 12/16/06 9:38 AM Here's a note that I received from Ken Westerback, some weeks ago and his take on why these two variables were removed from the include file: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/mtio.h It would appear I removed them since they are not implemented, as of r1.7. I think leaving them in but unimplemented is just misleading. Software that does not function in the absence of this information will be more readily identified if it can't compile. :-). I guess you can add them back to get the compile working, or patch bacula to not touch them. If you have some strong reasons for adding them back to the standard system I'm willing to listen. Ken Kenneth R Westerback Technology Architect, Corporate Resources St. Michael's Hospital 30 Bond Street Toronto, Ontario M5B 1W8 Office: 416-864-5981 e-Mail: [EMAIL PROTECTED] www.stmichaelshospital.com On 13/12/06, Kern Sibbald [EMAIL PROTECTED] wrote
Re: [Bacula-users] Building bacula on OpenBSD
On Tuesday 10 April 2007 15:52, Brian A. Seklecki wrote:
It looks like some significant improvements have been made to st(4):
http://www.openbsd.org/plus41.html
Make the st(4) SCSI Tape midlayer return values when receiving a
MTIOCGET ioctl, allows things like Bacula to work much
Nice.
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/st.c
Thank you for all who contributed to that. Should we return attention
to getting a comprehensive Bacula port committed?
Normally, there should be nothing to do other than build Bacula on OpenBSD.
Now that MTIOCGET has mt_blkno and mt_fileno defined there should be no major
obstacles.
Then try running btape.
~BAS
On Fri, 2006-12-22 at 19:09 +0100, Kern Sibbald wrote:
On Sunday 17 December 2006 18:45, Kenneth Westerback wrote:
Thanks for bringing this discussion to my attention Russell. If someone
can point me at the standard or other justification a 'Unix' system
requiring mt_blkno and mt_fileno in the mtget structure I'd be more than
happy to put them back. I would be even happier if someone could direct
me to a discussion on what the mandated or recommended action is for
these fields when the OS cannot supply any meaningful information. I
note that HPUX seems to always put -1 in them.
Well, the best justification for a Unix standard would be Posix, but
unfortunately Posix (at least my somewhat old Posix book) does not talk
about
tape operations.
However, FreeBSD, Linux, and Solaris all support MTIOCGET with the
mt_fileno
and mt_blkno fields in the packet. On some OS the values returned may not
be
valid, or may not be valid under certain circumstances (e.g. backspace
record
or backspace file or space to end of medium). Bacula's tape driver
references both mt_fileno and mt_blkno and thus if they do not exist, the
Storage daemon (tape driver part will not compile). However, the user can
configure his Bacula driver (in bacula-sd.conf) to essentially not do or
ignore the values returned from MTIOCGET. Doing so makes tape operations
painfully slow because Bacula must simulate what the kernel SCSI driver
can
do much more efficiently.
Setting mt_fileno and mt_blkno to -1 indicates to any tape I/O aware
program
such as Bacula that the value is unknown to the SCSI driver, and the
program
must take appropriate action ... as a consequence, I would see no great
harm
in defining those fields and always returning -1 in them. Doing so, would
probably also permit additional Open Source to compile and run on OpenBSD
without specific OpenBSD #ifdefing.
Whatever the case may be, the Bacula tape driver already has a lot of
#ifdefing in it to adapt to different systems, so I wouldn't be very
inclined
to #ifdef it so that it does not reference mt_fileno and mt_blkno unless
there were several systems that needed such a change.
Ken
Kenneth R Westerback
Technology Architect, Corporate Resources
St. Michael's Hospital
30 Bond Street
Toronto, Ontario
M5B 1W8
Office: 416-864-5981
e-Mail: [EMAIL PROTECTED]
www.stmichaelshospital.com
This message may contain privileged and confidential information and is
intended solely for the use of the intended recipient. If you are
neither the intended recipient nor the employee or agent responsible for
delivering this communication to the intended recipient, you are hereby
notified that any disclosure, copying or distribution of, or the taking
of any action in reliance on the contents of this communication is
strictly prohibited. If you have received this communication in error,
please notify us immediately by e-Mail at [EMAIL PROTECTED]
or telephone at 416-864-5981. Thank you.
Russell Sutherland [EMAIL PROTECTED] 12/16/06 9:38 AM
Here's a note that I received from Ken Westerback, some weeks ago
and his take on why these two variables were removed
from the include file:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/mtio.h
It would appear I removed them since they are not implemented, as of
r1.7. I think leaving them in but unimplemented is just misleading.
Software that does not function in the absence of this information will
be more readily identified if it can't compile. :-).
I guess you can add them back to get the compile working, or patch
bacula to not touch them. If you have some strong reasons for adding
them back to the standard system I'm willing to listen.
Ken
Kenneth R Westerback
Technology Architect, Corporate Resources
St. Michael's Hospital
30 Bond Street
Toronto, Ontario
M5B 1W8
Office: 416-864-5981
e-Mail: [EMAIL PROTECTED]
www.stmichaelshospital.com
On 13/12/06, Kern Sibbald [EMAIL PROTECTED] wrote:
Hello,
Since this is directed to me, and assuming I wrote the double 'ed
Re: [Bacula-users] Building bacula on OpenBSD
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 OpenBSD 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 (at 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) and recent HBA support. Anyway, not a director, not now at least, and probably not a SD Storage 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 file directly sys/mtio.h. Sorry, but you are pretty much on your own on this. == Error in /usr/local/src/bacula-1.38.11/src/stored == ==Entering directory /usr/local/src/bacula-1.38.11/src/tools Make of tools is good
Re: [Bacula-users] Building bacula on OpenBSD
Here is a functional FD on OpenBSD 4.0/i386: bash-3.2# uname -a OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0 GENERIC.MP+RAIDFRAME#1 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=0 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=client host=192.168.4.55 port=36387 vmware-sandbox-fd: find.c:81 init_find_files ff=-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 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5 [EMAIL PROTECTED] ssl=0 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=0 Job=*Console*.2006-12-13_13.09.33 SDid=0 SDtime=0 Authorization=dummy vmware-sandbox-fd: job.c:232 Executing JobId= command. vmware-sandbox-fd: job.c:435 JobId=0 Auth=dummy 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 The code for this may be found at: http://people.collaborativefusion.com/~seklecki/obsd_bacula.html This illustrates basic support. I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to have made it through: bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1016/10), delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=31100, relay=cvs.openbsd.org. [199.185.137.3], dsn=4.3.0, stat=Deferred: 451 Temporary failure, please try again later. Possibly greylisting~ ~BAS On Wed, 13 Dec 2006, Brian A. Seklecki wrote: 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 OpenBSD 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 (at 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) and recent HBA support. Anyway, not a director, not now at least, and probably not a SD Storage 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 file directly sys/mtio.h. Sorry, but you are pretty much on your own on this. == Error in
Re: [Bacula-users] Building bacula on OpenBSD
Just adding readline and OpenSSL support. Good to go now. ...OpenBSD doesn't have a portlint equiv, does it? ~BAS On Wed, 13 Dec 2006, GUILLON Gabriel wrote: This link: http://people.collaborativefusion.com/~seklecki/bacula_openbsd_port.tar seems to be broken Brian A. Seklecki a écrit : Here is a functional FD on OpenBSD 4.0/i386: bash-3.2# uname -a OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0 GENERIC.MP+RAIDFRAME#1 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=0 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=client host=192.168.4.55 port=36387 vmware-sandbox-fd: find.c:81 init_find_files ff=-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 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5 [EMAIL PROTECTED] ssl=0 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=0 Job=*Console*.2006-12-13_13.09.33 SDid=0 SDtime=0 Authorization=dummy vmware-sandbox-fd: job.c:232 Executing JobId= command. vmware-sandbox-fd: job.c:435 JobId=0 Auth=dummy 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 The code for this may be found at: http://people.collaborativefusion.com/~seklecki/obsd_bacula.html This illustrates basic support. I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to have made it through: bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1016/10), delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=31100, relay=cvs.openbsd.org. [199.185.137.3], dsn=4.3.0, stat=Deferred: 451 Temporary failure, please try again later. Possibly greylisting~ ~BAS On Wed, 13 Dec 2006, Brian A. Seklecki wrote: 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 OpenBSD 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 (at 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) and recent HBA support. Anyway, not a director, not now at least, and probably not a SD Storage 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
Re: [Bacula-users] Building bacula on OpenBSD
Hello,
Since this is directed to me, and assuming I wrote the double 'ed sections
below (which sound a lot like me but so much is snipped that I cannot be
sure), I can assure you that, my intention, if I am the guity party was not
to insult any person or any particular OS, but just to point out that it
appears to me to be an OS compatibility problem (actually a system header
file to be more correct).
See notes below, where I assume that I wrote the offending statements:
On Wednesday 13 December 2006 18:28, Brian A. Seklecki wrote:
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.
I'm sorry, I did not intend to be vendor bashing. I stand by what is written.
If it is a Unix system and there are not mt_fileno and mt_blkno in the struct
mtget, there are serious compatibility problems, since I don't have an
OpenBSD system, assuming the OS is not going to change, we would need a patch
to Bacula to fix it.
Moreover, conceding the unavailability of compatibility with the OpenBSD
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.
Yes, broken was a poor choice of words. I would rephrase it to say it is not
Unix compatible.
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 (at
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) and
recent HBA support.
Anyway, not a director, not now at least, and probably not a SD Storage
Daemon either.
Yes, since the problem above arises when compiling the SD.
But most definitely a management console and file daemon.
I think these already exist. Bacula does have some code to support OpenBSD.
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.
Without a decent implementation of pthreads, even the client (file daemon)
will not build.
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 file
directly sys/mtio.h. Sorry, but you are pretty much on your own on this.
== Error in /usr/local/src/bacula-1.38.11/src/stored ==
==Entering directory /usr/local/src/bacula-1.38.11/src/tools
Make of tools is good
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Building bacula on OpenBSD
This link: http://people.collaborativefusion.com/~seklecki/bacula_openbsd_port.tar seems to be broken Brian A. Seklecki a écrit : Here is a functional FD on OpenBSD 4.0/i386: bash-3.2# uname -a OpenBSD vmware-sandbox.pgh.priv.collaborativefusion.com 4.0 GENERIC.MP+RAIDFRAME#1 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=0 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=client host=192.168.4.55 port=36387 vmware-sandbox-fd: find.c:81 init_find_files ff=-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 [EMAIL PROTECTED] ssl=0 vmware-sandbox-fd: cram-md5.c:131 cram-get: auth cram-md5 [EMAIL PROTECTED] ssl=0 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=0 Job=*Console*.2006-12-13_13.09.33 SDid=0 SDtime=0 Authorization=dummy vmware-sandbox-fd: job.c:232 Executing JobId= command. vmware-sandbox-fd: job.c:435 JobId=0 Auth=dummy 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 The code for this may be found at: http://people.collaborativefusion.com/~seklecki/obsd_bacula.html This illustrates basic support. I've submited sendbug(1) to OpenBSD GNATS, but it does not appear to have made it through: bash-3.2$ Nov 12 09:08:11 vmware-sandbox sm-mta[10302]: kACE7scF013066: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1016/10), delay=00:00:16, xdelay=00:00:16, mailer=esmtp, pri=31100, relay=cvs.openbsd.org. [199.185.137.3], dsn=4.3.0, stat=Deferred: 451 Temporary failure, please try again later. Possibly greylisting~ ~BAS On Wed, 13 Dec 2006, Brian A. Seklecki wrote: 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 OpenBSD 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 (at 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) and recent HBA support. Anyway, not a director, not now at least, and probably not a SD Storage 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
