Re: [Bacula-users] Lack Persistent Device Naming to use with Alert Command

2019-01-29 Thread Nate K
Thanks for explaining how to check the ATTRS value!  The rules file works
well now.  Awesome!

On Tue, Jan 29, 2019 at 6:50 PM Adam Nielsen  wrote:

> > I ended up figuring out on accident my udev rules file did work, I had
> just
> > been trying to test it by restarting the service but it took a full
> reboot
> > for the new rules to get loaded.
>
> Normally you do something like this[1]:
>
>   # udevadm control --reload-rules && udevadm trigger
>
> > *SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}!="8",
>
> This will match all devices that are not type 8 (so everything except
> autochangers).
>
> > This ends up creating symlinks for every sg* device, not just the tape
> > drives, so ideally it would be nice to figure out how to filter it.
>
> If you want to restrict it to a particular type, you can view udev
> attributes for specific devices like this:
>
>   # udevadm info -a -n /dev/sch0 | grep type
> ATTRS{type}=="8"
>
>   # udevadm info -a -n /dev/nst0 | grep type
> ATTRS{type}=="1"
>
> Here it suggests that changing the rule from type 8 to type 1 will only
> match tape drives.  On my system a DVD drive is 5 and a hard drive is
> 0, so I guess using type 1 should work for tapes only.
>
> Cheers,
> Adam.
>
> [1]:
> https://unix.stackexchange.com/questions/39370/how-to-reload-udev-rules-without-reboot
>
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] Automation restore backup job

2019-01-29 Thread Bill Arlofski

On 1/23/19 4:53 AM, Petar Kozic wrote:

Thank you Bill.
Sure, I will contact you next week.
Best regards.


On 1/29/19 1:56 AM, Petar Kozic wrote:> Hi Bill,
> just reminder to post your scripts :)
> Thank you !


Hello Petar,

Well, safely back home in the US, recovering from a very busy week and long 
travel day back. :)


OK, for now, I have attached my AutoRestoreAndVeryfy.sh script.


It may be run from a RunScript in a Backup job or an Admin job, from cron, or 
even manually. You just need to make sure the correct command line parameters 
are supplied.


I think it is pretty well documented in comments near the top. Please take a 
look there to understand some of the details and limitations.


Currently it will restore the entire backup job, then run each type of verify 
job against the backup job. It will "wait" for each job to finish before 
initiating the next. If you do not want any of the verify jobs and only want 
the restore job, it is just a matter of removing or commenting all of those steps.


At some point, perhaps after some feedback and additional modifications I will 
post it to my website, but for now, I just wanted to get this out there to you.


For example, I am thinking that I might want to add the ability to specify the 
types of jobs to run on the command line, a different client to restore to, etc.


I have been running a version of this for a couple years now, and have just 
made a couple minor modifications today, so I think it is pretty stable.


All comments and suggestions welcome!


Best regards,

Bill


--
Bill Arlofski
http://www.revpol.com/bacula
-- Not responsible for anything below this line --


AutoRestoreAndVerify.sh
Description: application/shellscript
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] Lack Persistent Device Naming to use with Alert Command

2019-01-29 Thread Adam Nielsen
> I ended up figuring out on accident my udev rules file did work, I had just
> been trying to test it by restarting the service but it took a full reboot
> for the new rules to get loaded.

Normally you do something like this[1]:

  # udevadm control --reload-rules && udevadm trigger

> *SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}!="8",

This will match all devices that are not type 8 (so everything except
autochangers).

> This ends up creating symlinks for every sg* device, not just the tape
> drives, so ideally it would be nice to figure out how to filter it.

If you want to restrict it to a particular type, you can view udev
attributes for specific devices like this:

  # udevadm info -a -n /dev/sch0 | grep type
ATTRS{type}=="8"

  # udevadm info -a -n /dev/nst0 | grep type
ATTRS{type}=="1"

Here it suggests that changing the rule from type 8 to type 1 will only
match tape drives.  On my system a DVD drive is 5 and a hard drive is
0, so I guess using type 1 should work for tapes only.

Cheers,
Adam.

[1]: 
https://unix.stackexchange.com/questions/39370/how-to-reload-udev-rules-without-reboot


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


[Bacula-users] Installation of 9.x.x.

2019-01-29 Thread Hodges
Am following the Bacula Community Installation Guide in an attempt to 
upgrade from 5.0 to 9.20. I am on debian Jessie running on i686


Stuck at the end of paragraph 4.3 and start of 4.4. When I run apt-get 
update I get the following


Quote

Err:13 
https://www.bacula.org/packages/5c46fdc554a35/debs/9.2.0./jessie/amd64 
jessie Release
  Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the 
certificate verification. [IP: 80.244.178.6 443]

Reading package lists... Done
W: 
http://www.bacula.org/packages/5c46fdc554a35/debs/9.2.0./jessie/amd64/dists/jessie/InRelease: 
No system certificates available. Try installing ca-certificate s.
W: 
http://www.bacula.org/packages/5c46fdc554a35/debs/9.2.0./jessie/amd64/dists/jessie/Release: 
No system certificates available. Try installing ca-certificates.
E: The repository 
'http://www.bacula.org/packages/5c46fdc554a35/debs/9.2.0./jessie/amd64 
jessie Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is 
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user 
configuration details.


Unquote

Just on the offchance I ran apt-get install bacula-postgresql, but of 
course I just got 'cannot locate package bacula-postgresql'.


I can install bacula 9.4.1 from the debian repositories but it doesn't 
install with same configuration as the Installation Guide, does not seem 
to recognise systemd and generally does not work


I tried compiling from source from Heitor Faria's website, but that 
doesn't work either for me at keast


Can anyone help?

Steve

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] [External] Re: [Bacula-devel] IBAdmin

2019-01-29 Thread Dan Langille
> On Jan 28, 2019, at 1:19 PM, Radosław Korzeniewski 
>  wrote:
> 
> Hello Kern,
> 
> pt., 25 sty 2019 o 16:47 Kern Sibbald  > napisał(a):
> Hello guys,
> 
> Interesting conversation.  I thought I would throw in some general comments 
> of my own.
> 
> - I really like seeing another GUI for Bacula, because it is something we 
> really need.
> 
> Thank you Kern, I really appreciate your support. You are the only one who 
> sees it as an opportunity and not a threat.

I think that's unfair.

I hope you have not taken the suggestions provided here are the result of 
viewing IBAdmin as a threat. They are not.

I hope you have not taken the suggestions for improvement as an attack on 
IBAdmin. They are not.

It is relatively straight forward, I should hope, to identify the parts of the 
database you need to read and the parts you need to update.

I recently did similar for another application:

It looks something like this:

create role freshsource_ro;
GRANT SELECT ON TABLE public.commit_log TO freshsource_ro;
GRANT SELECT ON TABLE public.commit_log_elements TO freshsource_ro;
GRANT SELECT ON TABLE public.element TO freshsource_ro;
GRANT SELECT ON TABLE public.latest_commits TO freshsource_ro;
GRANT SELECT ON TABLE public.repo TO freshsource_ro;
GRANT SELECT ON TABLE public.security_notice TO freshsource_ro;
GRANT SELECT ON TABLE public.system TO freshsource_ro;
GRANT SELECT ON TABLE public.users TO freshsource_ro;
GRANT UPDATE(cookie) ON TABLE public.users TO freshsource_ro;
GRANT UPDATE(lastlogin) ON TABLE public.users TO freshsource_ro;
GRANT SELECT ON TABLE public.watch_list TO freshsource_ro;
GRANT SELECT ON TABLE public.watch_list_element TO freshsource_ro;
GRANT SELECT ON TABLE public.watch_notice TO freshsource_ro;

Then a user is created and added to that freshsource_ro role:

create user freshsource_dev with password '[redacted]' IN ROLE freshsource_ro;

Nobody sees the application itself as threat.

These are straight forward security practices which are carried out in many 
organizations, both small and large.

Best wishes.

--
Dan Langille - BSDCan / PGCon
d...@langille.org



signature.asc
Description: Message signed with OpenPGP
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] Lack Persistent Device Naming to use with Alert Command

2019-01-29 Thread Nate K
I ended up figuring out on accident my udev rules file did work, I had just
been trying to test it by restarting the service but it took a full reboot
for the new rules to get loaded.  This was what I did:

*> cat /etc/udev/rules.d/70-scsictrldev.rules*
*SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}!="8",
IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d
$devnode", \*
*  SYMLINK+="tape/by-id/scsi-$env{ID_SERIAL}-sg"*

This ends up creating symlinks for every sg* device, not just the tape
drives, so ideally it would be nice to figure out how to filter it.  The
extra symlinks are just clutter though and don't harm anything so I'll call
this good for now.

Thanks,
Nate

On Mon, Jan 28, 2019 at 7:07 PM Nate K  wrote:

> I tried creating a new rules file based on the existing tape rules but I
> didn't have any luck making it work and I didn't know how to debug what I'd
> done.  I ended up creating this bash script to create the symlinks and it
> worked so I think I'll call it good:
>
> *#!/bin/bash*
>
> *#create persistent device paths for tape drive control devices*
>
> *n=($(ls /dev | grep sg[0123456789]))*
>
> *for i in "${n[@]}"*
> *do*
> *model=($(/lib/udev/scsi_id --page=0x80 --whitelisted /dev/$i))*
> *if [ "$model" == "SIBM" ]; then*
> *serial=($(/lib/udev/scsi_id --page=0x83 --whitelisted /dev/$i))*
> *ln -s /dev/$i /dev/tape/by-id/scsi-$serial-sg*
> *fi*
> *done*
>
> A udev rule would be nice because it could work for a lot of users using
> different hardware but I've run out of patience.  This script can be
> adapted for other hardware simply by changing the "SIBM" model to the
> output of the" scsi_id --page=0x80" command for a different model drive.
>
> Thanks,
> Nate
>
>
> On Sun, Jan 27, 2019 at 9:14 PM Nate K  wrote:
>
>> This is the rules file, I will have to spend some time going through it.
>> Thanks.
>>
>> *> cat /lib/udev/rules.d/60-persistent-storage-tape.rules*
>> *# do not edit this file, it will be overwritten on update*
>>
>> *# persistent storage links: /dev/tape/{by-id,by-path}*
>>
>> *ACTION=="remove", GOTO="persistent_storage_tape_end"*
>> *ENV{UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG}=="1",
>> GOTO="persistent_storage_tape_end"*
>>
>> *# type 8 devices are "Medium Changers"*
>> *SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="8",
>> IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d
>> $devnode", \*
>> *  SYMLINK+="tape/by-id/scsi-$env{ID_SERIAL}"*
>>
>> *SUBSYSTEM!="scsi_tape", GOTO="persistent_storage_tape_end"*
>>
>> *KERNEL=="st*[0-9]|nst*[0-9]", ATTRS{ieee1394_id}=="?*",
>> ENV{ID_SERIAL}="$attr{ieee1394_id}", ENV{ID_BUS}="ieee1394"*
>> *KERNEL=="st*[0-9]|nst*[0-9]", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="usb",
>> IMPORT{builtin}="usb_id"*
>> *KERNEL=="st*[0-9]|nst*[0-9]", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi",
>> KERNELS=="[0-9]*:*[0-9]", ENV{.BSG_DEV}="$root/bsg/$id"*
>> *KERNEL=="st*[0-9]|nst*[0-9]", ENV{ID_SERIAL}!="?*",
>> IMPORT{program}="scsi_id --whitelisted --export --device=$env{.BSG_DEV}",
>> ENV{ID_BUS}="scsi"*
>> *KERNEL=="st*[0-9]",  ENV{ID_SERIAL}=="?*",
>> SYMLINK+="tape/by-id/$env{ID_BUS}-$env{ID_SERIAL}"*
>> *KERNEL=="nst*[0-9]", ENV{ID_SERIAL}=="?*",
>> SYMLINK+="tape/by-id/$env{ID_BUS}-$env{ID_SERIAL}-nst"*
>>
>> *# by-path (parent device path)*
>> *KERNEL=="st*[0-9]|nst*[0-9]", IMPORT{builtin}="path_id"*
>> *KERNEL=="st*[0-9]", ENV{ID_PATH}=="?*",
>> SYMLINK+="tape/by-path/$env{ID_PATH}"*
>> *KERNEL=="nst*[0-9]", ENV{ID_PATH}=="?*",
>> SYMLINK+="tape/by-path/$env{ID_PATH}-nst"*
>>
>> *LABEL="persistent_storage_tape_end"*
>>
>>
>> On Sun, Jan 27, 2019 at 3:14 AM Adam Nielsen 
>> wrote:
>>
>>> > There are symlinks for the archive devices but not the tape drive
>>> control
>>> > devices which is what the tape alert commands need.
>>>
>>> Ah I see, you need the /dev/sg* equivalent for the /dev/st* in use.
>>>
>>> Can you copy the udev rules that produce symlinks for the autochangers
>>> (see link in my last post) and tweak them so that they also work for the
>>> drives themselves?  It looks like they pick up anything that's a
>>> "type 8" device so if you duplicate the rule but change it to whatever
>>> type number that tape drives are, presumably you'd end up with the same
>>> result.
>>>
>>> > My only other idea is that maybe you could create a script that
>>> rewrites
>>> > the bacula-sd.conf every boot by parsing the output of this command as
>>> it
>>> > shows which sg* devices correspond to the st* ones:
>>>
>>> If you wanted to do that it might be easier to have the script
>>> create/update symlinks in /dev so you don't need to rewrite the Bacula
>>> config file.  But this is pretty much what udev does already so better
>>> to get that working if you can.
>>>
>>> Cheers,
>>> Adam.
>>>
>>
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] Automation restore backup job

2019-01-29 Thread Petar Kozic
Hi Bill,
just reminder to post your scripts :)
Thank you !


On January 23, 2019 at 12:53:41 PM, Petar Kozic (petar.ko...@gmail.com)
wrote:

Thank you Bill.
Sure, I will contact you next week.
Best regards.

On January 23, 2019 at 12:46:18 PM, Bill Arlofski (waa-bac...@revpol.com)
wrote:

On 1/23/19 4:27 AM, Petar Kozic wrote:
> Hi folks,
> I try to find some solution on the internet but I found only parcial
> solution.
> I want to hear from you what you think about automation restore backup
> for test purpose.
>
> Indeed, I have about 25 linux instance which I backuping on my bacula
> server. My configuration files was splitted for every client in
particular.
> By, default every backup job for client have also defined restore job on
> same client.
>
> I want to create one test linux instance where I can randomly to start
> some restore from bacula to test instance to check does backup is ok.
> I will automate all other staff as start of test and check restore with
> some app as Jenkins or Ansible etc…
>
> I need solution on which way I can make some automation job for restore
> randomly client on my test instance, is that possible from bash and how,
> or maybe from mysql query and how etc...
>
> Thank’s in advanced.
>
> *—*
> *Petar Kozić*


Hello Petar,

I have a rather extensive script to not only do a restore like you ask,
but it can also automatically run all of the verifies jobs too..

I am currently in Switzerland at a company meeting, but when I get back
to my office next week, I can forward you this script...

And, now that I think about it, I will probably also post it to my
website with the rest of the Bacula-related scripts I have posted. :)

http://www.revpol.com/bacula has some other things that might be useful...

Please ping me next week if I forget to post it.

Best regards,

Bill

--
Bill Arlofski
Reverse Polarity, LLC
860-824-2433 Office
860-965-5110 Cell
http://www.revpol.com/
--
He picks up scraps of information
He's adept at adaptation

Learn about strong cryptography and how it can protect your personal
communications from the NSA's illegal spying programs here:
https://en.wikipedia.org/wiki/Pretty_Good_Privacy

This communication may be unlawfully collected and stored by the
National Security Agency (NSA) in secret. The parties to this email do
not consent to the retrieving or storing of this communication and any
related metadata, as well as printing, copying, re-transmitting,
disseminating, or otherwise using it. If you have received this
communication in error (or illegally - by mass collection and/or
spying), you are required to delete it immediately.

--
--
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/
-- Not responsible for anything below this line --


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users