Backup Central

Linux gurus,

I'm flailing away here trying to get some udev rules in place on RedHat
release 4, Nahant Update 5. I'm basically trying to accomplish this:

http://kbase.redhat.com/faq/docs/DOC-4202

But with an earlier version of RedHat. Anyone have experience with udev
rules out there? I've posted prior to this with very few bites, but
there doesn't seem to be a lot of admins out there creating these (I'm
guessing people just recreate their device database after every
reboot?).

Here are the rules I've created:

[root < at > <> ~]# more /etc/udev/rules.d/10-local.rules
KERNEL="nst[0-9]*", SYSFS{dev}="9:128", NAME="nst100"
KERNEL="nst[0-9]*", SYSFS{dev}="9:224", NAME="nst100a"
KERNEL="nst[0-9]*", SYSFS{dev}="9:160", NAME="nst100l"
KERNEL="nst[0-9]*", SYSFS{dev}="9:192", NAME="nst100m"

KERNEL="st[0-9]*", SYSFS{dev}="9:0", NAME="st100"
KERNEL="st[0-9]*", SYSFS{dev}="9:96", NAME="st100a"
KERNEL="st[0-9]*", SYSFS{dev}="9:32", NAME="st100l"
KERNEL="st[0-9]*", SYSFS{dev}="9:64", NAME="st100m"

And the udevtest's I run seem to work (for example):

[root < at > <> ~]# udevtest /class/scsi_tape/nst0
version 039
looking at '/class/scsi_tape/nst0'
configured rule in '/etc/udev/rules.d/10-local.rules' at line 1 applied,
'nst0' becomes 'nst100'
creating device node '/dev/nst100', major = '9', minor = '128', mode =
'020660', uid = '0', gid = '6'

And my /etc/rc.local file to make it automatic after each reboot has the
lines right at the end:

/sbin/start_udev
/dev/MAKEDEV sg

From what I can tell, my nst and st files get created ok (do I even need
st devices with Netbackup 6.5 MP3.1?). Running the following fails
however, without finding the /dev/nst100 device path:
/usr/openv/volmgr/bin/scan

Any thoughts?

Thanks,
Jon
====================================================================================

La version française suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential information, and the Bank of
Canada does not waive any related rights. Any distribution, use, or copying of this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately from
your system and notify the sender promptly by email that you have done so.

------------------------------------------------------------------------------------

Le présent courriel peut contenir de l'information privilégiée ou confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre
ordinateur toute copie du courriel reçu.
_______________________________________________
Veritas-bu maillist - Veritas-bu < at > mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

I assume you’re doing this to help keep the devices from becoming mis-configured in NBU after a reboot - because the lack of persistent binding ends up changing the target number for the drives. We’ve always used ENABLE_AUTO_PATH_CORRECTION in the vm.conf file for this, which seems to work well.

-devon

------------------------------
Date: Tue, 4 Aug 2009 14:33:26 -0400
From: "Jonathan Dyck" <jdyck < at > bank-banque-canada.ca>
Subject: [Veritas-bu] Udev rules for Linux distros prior to 5.3...
To: <VERITAS-BU < at > mailman.eng.auburn.edu>
Message-ID:
<22D301D9B05B074F900C913A9550E93503838F < at > EXMAIL1.bocad.bank-banque-canada.ca>

Content-Type: text/plain; charset="utf-8"

Linux gurus,

I'm flailing away here trying to get some udev rules in place on RedHat
release 4, Nahant Update 5. I'm basically trying to accomplish this:

http://kbase.redhat.com/faq/docs/DOC-4202

But with an earlier version of RedHat. Anyone have experience with udev
rules out there? I've posted prior to this with very few bites, but
there doesn't seem to be a lot of admins out there creating these (I'm
guessing people just recreate their device database after every
reboot?).

Here are the rules I've created:

[root < at > <> ~]# more /etc/udev/rules.d/10-local.rules
KERNEL="nst[0-9]*", SYSFS{dev}="9:128", NAME="nst100"
KERNEL="nst[0-9]*", SYSFS{dev}="9:224", NAME="nst100a"
KERNEL="nst[0-9]*", SYSFS{dev}="9:160", NAME="nst100l"
KERNEL="nst[0-9]*", SYSFS{dev}="9:192", NAME="nst100m"

KERNEL="st[0-9]*", SYSFS{dev}="9:0", NAME="st100"
KERNEL="st[0-9]*", SYSFS{dev}="9:96", NAME="st100a"
KERNEL="st[0-9]*", SYSFS{dev}="9:32", NAME="st100l"
KERNEL="st[0-9]*", SYSFS{dev}="9:64", NAME="st100m"

And the udevtest's I run seem to work (for example):

[root < at > <> ~]# udevtest /class/scsi_tape/nst0
version 039
looking at '/class/scsi_tape/nst0'
configured rule in '/etc/udev/rules.d/10-local.rules' at line 1 applied,
'nst0' becomes 'nst100'
creating device node '/dev/nst100', major = '9', minor = '128', mode =
'020660', uid = '0', gid = '6'

And my /etc/rc.local file to make it automatic after each reboot has the
lines right at the end:

/sbin/start_udev
/dev/MAKEDEV sg

From what I can tell, my nst and st files get created ok (do I even need
st devices with Netbackup 6.5 MP3.1?). Running the following fails
however, without finding the /dev/nst100 device path:
/usr/openv/volmgr/bin/scan

Any thoughts?

Thanks,
Jon
====================================================================================

La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential information, and the Bank of
Canada does not waive any related rights. Any distribution, use, or copying of this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately from
your system and notify the sender promptly by email that you have done so.

------------------------------------------------------------------------------------

Le pr?sent courriel peut contenir de l'information privil?gi?e ou confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires d?sign?s est interdite. Si vous recevez
ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans d?lai ?
l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de votre
ordinateur toute copie du courriel re?u.

Yes, exactly. I'm not really sure how that flag works, although I've recently put it in. Does it basically run the equivalent of the device manager wizard and update all /dev/nst# records each time NBU stop/starts?

Thanks,
Jon


-----Original Message-----
From: Peters, Devon C [mailto:Peters.Devon < at > con-way.com]
Sent: August 05, 2009 8:05 PM
To: Jonathan Dyck; veritas-bu < at > mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Udev rules for Linux distros prior to 5.3...


I assume you’re doing this to help keep the devices from becoming mis-configured in NBU after a reboot - because the lack of persistent binding ends up changing the target number for the drives. We’ve always used ENABLE_AUTO_PATH_CORRECTION in the vm.conf file for this, which seems to work well.

-devon

------------------------------
Date: Tue, 4 Aug 2009 14:33:26 -0400
From: "Jonathan Dyck" <jdyck < at > bank-banque-canada.ca>
Subject: [Veritas-bu] Udev rules for Linux distros prior to 5.3...
To: <VERITAS-BU < at > mailman.eng.auburn.edu>
Message-ID:
<22D301D9B05B074F900C913A9550E93503838F < at > EXMAIL1.bocad.bank-banque-canada.ca>

Content-Type: text/plain; charset="utf-8"

Linux gurus,

I'm flailing away here trying to get some udev rules in place on RedHat
release 4, Nahant Update 5. I'm basically trying to accomplish this:

http://kbase.redhat.com/faq/docs/DOC-4202

But with an earlier version of RedHat. Anyone have experience with udev
rules out there? I've posted prior to this with very few bites, but
there doesn't seem to be a lot of admins out there creating these (I'm
guessing people just recreate their device database after every
reboot?).

Here are the rules I've created:

[root < at > <> ~]# more /etc/udev/rules.d/10-local.rules
KERNEL="nst[0-9]*", SYSFS{dev}="9:128", NAME="nst100"
KERNEL="nst[0-9]*", SYSFS{dev}="9:224", NAME="nst100a"
KERNEL="nst[0-9]*", SYSFS{dev}="9:160", NAME="nst100l"
KERNEL="nst[0-9]*", SYSFS{dev}="9:192", NAME="nst100m"

KERNEL="st[0-9]*", SYSFS{dev}="9:0", NAME="st100"
KERNEL="st[0-9]*", SYSFS{dev}="9:96", NAME="st100a"
KERNEL="st[0-9]*", SYSFS{dev}="9:32", NAME="st100l"
KERNEL="st[0-9]*", SYSFS{dev}="9:64", NAME="st100m"

And the udevtest's I run seem to work (for example):

[root < at > <> ~]# udevtest /class/scsi_tape/nst0
version 039
looking at '/class/scsi_tape/nst0'
configured rule in '/etc/udev/rules.d/10-local.rules' at line 1 applied,
'nst0' becomes 'nst100'
creating device node '/dev/nst100', major = '9', minor = '128', mode =
'020660', uid = '0', gid = '6'

And my /etc/rc.local file to make it automatic after each reboot has the
lines right at the end:

/sbin/start_udev
/dev/MAKEDEV sg

From what I can tell, my nst and st files get created ok (do I even need
st devices with Netbackup 6.5 MP3.1?). Running the following fails
however, without finding the /dev/nst100 device path:
/usr/openv/volmgr/bin/scan

Any thoughts?

Thanks,
Jon
====================================================================================

La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential information, and the Bank of
Canada does not waive any related rights. Any distribution, use, or copying of this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately from
your system and notify the sender promptly by email that you have done so.

------------------------------------------------------------------------------------

Le pr?sent courriel peut contenir de l'information privil?gi?e ou confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires d?sign?s est interdite. Si vous recevez
ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans d?lai ?
l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de votre
ordinateur toute copie du courriel re?u.


====================================================================================

La version française suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential information, and the Bank of
Canada does not waive any related rights. Any distribution, use, or copying of this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately from
your system and notify the sender promptly by email that you have done so.

------------------------------------------------------------------------------------

Le présent courriel peut contenir de l'information privilégiée ou confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre
ordinateur toute copie du courriel reçu.

I believe it tracks the drives by serial number.  When you reboot you’ll notice that the device paths get automatically updated.

-devon

From: Jonathan Dyck [mailto:jdyck < at > bank-banque-canada.ca]
Sent: Thursday, August 06, 2009 6:12 AM
To: Peters, Devon C; veritas-bu < at > mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Udev rules for Linux distros prior to 5.3...



Yes, exactly. I'm not really sure how that flag works, although I've recently put it in. Does it basically run the equivalent of the device manager wizard and update all /dev/nst# records each time NBU stop/starts?



Thanks,

Jon



-----Original Message-----
From: Peters, Devon C [mailto:Peters.Devon < at > con-way.com]
Sent: August 05, 2009 8:05 PM
To: Jonathan Dyck; veritas-bu < at > mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Udev rules for Linux distros prior to 5.3...
I assume you’re doing this to help keep the devices from becoming mis-configured in NBU after a reboot - because the lack of persistent binding ends up changing the target number for the drives. We’ve always used ENABLE_AUTO_PATH_CORRECTION in the vm.conf file for this, which seems to work well.



-devon



------------------------------

Date: Tue, 4 Aug 2009 14:33:26 -0400

From: "Jonathan Dyck" <jdyck < at > bank-banque-canada.ca>

Subject: [Veritas-bu] Udev rules for Linux distros prior to 5.3...

To: <VERITAS-BU < at > mailman.eng.auburn.edu>

Message-ID:

<22D301D9B05B074F900C913A9550E93503838F < at > EXMAIL1.bocad.bank-banque-canada.ca>



Content-Type: text/plain; charset="utf-8"



Linux gurus,



I'm flailing away here trying to get some udev rules in place on RedHat

release 4, Nahant Update 5. I'm basically trying to accomplish this:



http://kbase.redhat.com/faq/docs/DOC-4202



But with an earlier version of RedHat. Anyone have experience with udev

rules out there? I've posted prior to this with very few bites, but

there doesn't seem to be a lot of admins out there creating these (I'm

guessing people just recreate their device database after every

reboot?).



Here are the rules I've created:



[root < at > <> ~]# more /etc/udev/rules.d/10-local.rules

KERNEL="nst[0-9]*", SYSFS{dev}="9:128", NAME="nst100"

KERNEL="nst[0-9]*", SYSFS{dev}="9:224", NAME="nst100a"

KERNEL="nst[0-9]*", SYSFS{dev}="9:160", NAME="nst100l"

KERNEL="nst[0-9]*", SYSFS{dev}="9:192", NAME="nst100m"



KERNEL="st[0-9]*", SYSFS{dev}="9:0", NAME="st100"

KERNEL="st[0-9]*", SYSFS{dev}="9:96", NAME="st100a"

KERNEL="st[0-9]*", SYSFS{dev}="9:32", NAME="st100l"

KERNEL="st[0-9]*", SYSFS{dev}="9:64", NAME="st100m"



And the udevtest's I run seem to work (for example):



[root < at > <> ~]# udevtest /class/scsi_tape/nst0

version 039

looking at '/class/scsi_tape/nst0'

configured rule in '/etc/udev/rules.d/10-local.rules' at line 1 applied,

'nst0' becomes 'nst100'

creating device node '/dev/nst100', major = '9', minor = '128', mode =

'020660', uid = '0', gid = '6'



And my /etc/rc.local file to make it automatic after each reboot has the

lines right at the end:



/sbin/start_udev

/dev/MAKEDEV sg



From what I can tell, my nst and st files get created ok (do I even need

st devices with Netbackup 6.5 MP3.1?). Running the following fails

however, without finding the /dev/nst100 device path:

/usr/openv/volmgr/bin/scan



Any thoughts?



Thanks,

Jon

====================================================================================



La version fran?aise suit le texte anglais.



------------------------------------------------------------------------------------



This email may contain privileged and/or confidential information, and the Bank of

Canada does not waive any related rights. Any distribution, use, or copying of this

email or the information it contains by other than the intended recipient is

unauthorized. If you received this email in error please delete it immediately from

your system and notify the sender promptly by email that you have done so.



------------------------------------------------------------------------------------



Le pr?sent courriel peut contenir de l'information privil?gi?e ou confidentielle.

La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,

utilisation ou copie de ce courriel ou des renseignements qu'il contient par une

personne autre que le ou les destinataires d?sign?s est interdite. Si vous recevez

ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans d?lai ?

l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de votre

ordinateur toute copie du courriel re?u.




==================================================================================== La version française suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential information, and the Bank ofCanada does not waive any related rights. Any distribution, use, or copying of thisemail or the information it contains by other than the intended recipient isunauthorized. If you received this email in error please delete it immediately from 0 1 2 3 4 5 6 7 8 9La version française suit le texte anglais.0

That will interesting to test. So if I'm reading you correctly, things like the drive name, drive number and serial number would all stay the same for NBU, but the /dev/nst# could change after every reboot and the EMM database would be updated automatically.

Sounds like a tpconfig command is running each time before Netbackup services finish starting.

Will have to test it out!

Thanks Devon.

-----Original Message-----
From: Peters, Devon C [mailto:Peters.Devon < at > con-way.com]
Sent: August 06, 2009 12:41 PM
To: Jonathan Dyck; veritas-bu < at > mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Udev rules for Linux distros prior to 5.3...



I believe it tracks the drives by serial number. When you reboot you’ll notice that the device paths get automatically updated.

-devon

From: Jonathan Dyck [mailto:jdyck < at > bank-banque-canada.ca]
Sent: Thursday, August 06, 2009 6:12 AM
To: Peters, Devon C; veritas-bu < at > mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Udev rules for Linux distros prior to 5.3...



Yes, exactly. I'm not really sure how that flag works, although I've recently put it in. Does it basically run the equivalent of the device manager wizard and update all /dev/nst# records each time NBU stop/starts?



Thanks,

Jon



-----Original Message-----
From: Peters, Devon C [mailto:Peters.Devon < at > con-way.com]
Sent: August 05, 2009 8:05 PM
To: Jonathan Dyck; veritas-bu < at > mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Udev rules for Linux distros prior to 5.3...
I assume you’re doing this to help keep the devices from becoming mis-configured in NBU after a reboot - because the lack of persistent binding ends up changing the target number for the drives. We’ve always used ENABLE_AUTO_PATH_CORRECTION in the vm.conf file for this, which seems to work well.



-devon



------------------------------

Date: Tue, 4 Aug 2009 14:33:26 -0400

From: "Jonathan Dyck" <jdyck < at > bank-banque-canada.ca>

Subject: [Veritas-bu] Udev rules for Linux distros prior to 5.3...

To: <VERITAS-BU < at > mailman.eng.auburn.edu>

Message-ID:

<22D301D9B05B074F900C913A9550E93503838F < at > EXMAIL1.bocad.bank-banque-canada.ca>



Content-Type: text/plain; charset="utf-8"



Linux gurus,



I'm flailing away here trying to get some udev rules in place on RedHat

release 4, Nahant Update 5. I'm basically trying to accomplish this:



http://kbase.redhat.com/faq/docs/DOC-4202



But with an earlier version of RedHat. Anyone have experience with udev

rules out there? I've posted prior to this with very few bites, but

there doesn't seem to be a lot of admins out there creating these (I'm

guessing people just recreate their device database after every

reboot?).



Here are the rules I've created:



[root < at > <> ~]# more /etc/udev/rules.d/10-local.rules

KERNEL="nst[0-9]*", SYSFS{dev}="9:128", NAME="nst100"

KERNEL="nst[0-9]*", SYSFS{dev}="9:224", NAME="nst100a"

KERNEL="nst[0-9]*", SYSFS{dev}="9:160", NAME="nst100l"

KERNEL="nst[0-9]*", SYSFS{dev}="9:192", NAME="nst100m"



KERNEL="st[0-9]*", SYSFS{dev}="9:0", NAME="st100"

KERNEL="st[0-9]*", SYSFS{dev}="9:96", NAME="st100a"

KERNEL="st[0-9]*", SYSFS{dev}="9:32", NAME="st100l"

KERNEL="st[0-9]*", SYSFS{dev}="9:64", NAME="st100m"



And the udevtest's I run seem to work (for example):



[root < at > <> ~]# udevtest /class/scsi_tape/nst0

version 039

looking at '/class/scsi_tape/nst0'

configured rule in '/etc/udev/rules.d/10-local.rules' at line 1 applied,

'nst0' becomes 'nst100'

creating device node '/dev/nst100', major = '9', minor = '128', mode =

'020660', uid = '0', gid = '6'



And my /etc/rc.local file to make it automatic after each reboot has the

lines right at the end:



/sbin/start_udev

/dev/MAKEDEV sg



From what I can tell, my nst and st files get created ok (do I even need

st devices with Netbackup 6.5 MP3.1?). Running the following fails

however, without finding the /dev/nst100 device path:

/usr/openv/volmgr/bin/scan



Any thoughts?



Thanks,

Jon

====================================================================================



La version fran?aise suit le texte anglais.



------------------------------------------------------------------------------------



This email may contain privileged and/or confidential information, and the Bank of

Canada does not waive any related rights. Any distribution, use, or copying of this

email or the information it contains by other than the intended recipient is

unauthorized. If you received this email in error please delete it immediately from

your system and notify the sender promptly by email that you have done so.



------------------------------------------------------------------------------------



Le pr?sent courriel peut contenir de l'information privil?gi?e ou confidentielle.

La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion,

utilisation ou copie de ce courriel ou des renseignements qu'il contient par une

personne autre que le ou les destinataires d?sign?s est interdite. Si vous recevez

ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans d?lai ?

l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de votre

ordinateur toute copie du courriel re?u.




==================================================================================== La version française suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential information, and the Bank ofCanada does not waive any related rights. Any distribution, use, or copying of thisemail or the information it contains by other than the intended recipient isunauthorized. If you received this email in error please delete it immediately from 0 1 2 3 4 5 6 7 8 9La version française suit le texte anglais.0
La version française suit le texte anglais.1