Compiling a new RHEL-4 kernel

 

> -----Original Message-----
> From: redhat-list-bouncesredhat.com 
> [mailto:redhat-list-bouncesredhat.com] On Behalf Of
Simon
> Sent: Tuesday, December 20, 2005 12:48 AM
> To: General Red Hat Linux discussion list
> Subject: Compiling a new RHEL-4 kernel
> 
> Hi all,
> 
> Ok, I need to recompile my kernel to add in the 'scan
all LUNS for  
> each SCSI device' 

Would recompiling the kernel make the release
"unsupported" by redhat?
> -- 
> redhat-list mailing list
> unsubscribe mailto:redhat-list-requestredhat.com?subject=unsubscribe
> h
ttps://www.redhat.com/mailman/listinfo/redhat-list
> 
> 


-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-requestredhat.com?subject=unsubscribe
h
ttps://www.redhat.com/mailman/listinfo/redhat-list

First off, this will void your support contract. But to get
the kernel
sources, read the RHEL4 release notes available on redhat's
site.

As far as your tape changer issue, verify that sg5 is indeed
your
changer and not an individual tape device. Once you have
verified that,
create a symlink /dev/changer -> /dev/sg5

`mtx status` should then show you stats about your changer.

If you get stats, read the mtx manpage about how to
load/unload tapes.
If no stats appear, try a different sg device until you find
the correct
one.

NOTE: /dev/st0 will rewind the tape after each write,
/dev/nst0 will
not, I recommend if using a tape for backup, that you use
/dev/nst0, and
then manually issue a rewind at the end of the backup
functions. This
prevents you from inadvertantly overwriting previously
backup up data.

Thanks,

Tom Callahan
TESSCO Technologies
(443)-506-6216
callahanttessco.com

A real engineer only resorts to documentation when the
keyboard dents on the forehead get too noticeable.



Blackburn, Marvin wrote:

> 
>
>  
>
>>-----Original Message-----
>>From: redhat-list-bouncesredhat.com 
>>[mailto:redhat-list-bouncesredhat.com] On Behalf Of
Simon
>>Sent: Tuesday, December 20, 2005 12:48 AM
>>To: General Red Hat Linux discussion list
>>Subject: Compiling a new RHEL-4 kernel
>>
>>Hi all,
>>
>>Ok, I need to recompile my kernel to add in the
'scan all LUNS for  
>>each SCSI device' 
>>    
>>
>
>Would recompiling the kernel make the release
"unsupported" by redhat?
>  
>
>>-- 
>>redhat-list mailing list
>>unsubscribe mailto:redhat-list-requestredhat.com?subject=unsubscribe
>>h
ttps://www.redhat.com/mailman/listinfo/redhat-list
>>
>>
>>    
>>
>
>
>  
>

-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-requestredhat.com?subject=unsubscribe
h
ttps://www.redhat.com/mailman/listinfo/redhat-list

On Dec 20, 2005, at 6:25 AM, Tom Callahan wrote:

> First off, this will void your support contract. But to
get the kernel
> sources, read the RHEL4 release notes available on
redhat's site.
>
> As far as your tape changer issue, verify that sg5 is
indeed your
> changer and not an individual tape device. Once you
have verified  
> that,
> create a symlink /dev/changer -> /dev/sg5
>
> `mtx status` should then show you stats about your
changer.

The problem is that both robot and changer are set to
/dev/sg5 - the  
device uses different LUNs to distinguish and RHEL is set up
to not  
scan for different LUNs per SCSI device by default :-(

I get an ok response from the command:

	mtx -f /dev/sg5 inquiry

... but

	mtx -f /dev/sg5 status

... fails miserably.

> NOTE: /dev/st0 will rewind the tape after each write,
/dev/nst0 will
> not, I recommend if using a tape for backup, that you
use /dev/ 
> nst0, and
> then manually issue a rewind at the end of the backup
functions. This
> prevents you from inadvertantly overwriting previously
backup up data.

Yeah, I know - the tape is ~400GB (an Ultrium-3), so the
backup  
(~250GB) fits on fine, and there are 8 tapes in the device.
At the  
moment, the service people are using the front-panel
controls to  
manually switch tapes on a day-by-day basis. This gives us a
rolling  
backup for a week. When I get the tape robot working
properly, I'll  
start writing scripts to do both full and incremental
backups and  
load/unload tapes on-demand...

A new (clone) server will appear in the next few days, so
I'm going  
to wait until that arrives before fiddling with kernel
parameters  
(I'd rather test hardware on the machine that *isn't*
serving a few  
hundred websites [grin])

Thanks for the help though 

ATB,
	Simon
  

-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-requestredhat.com?subject=unsubscribe
h
ttps://www.redhat.com/mailman/listinfo/redhat-list

Very strange.... How many drives are in your robot? The
changer itself
is not really a device that would be seen by a scsi lun
probe, you
should see three luns if you have 2 drives for instance.

We have an HP MSL5026 here, along with a 5052, and with the
5026, I see
the robot as /dev/sg1 and the drives individually as
/dev/sg2, and sg3.

The 5052 is the same way, but two more drives as /dev/sg4
and sg5

What brand/model of robot are you using, and if possible,
can you give
me the output of lssg (part of fibreutils package) or
/proc/scsi/scsi??

I'm pretty sure this should work out of the box. I've never
had problems
otherwise.....

Thanks,

Tom Callahan
TESSCO Technologies
(443)-506-6216
callahanttessco.com

A real engineer only resorts to documentation when the
keyboard dents on the forehead get too noticeable.



Simon wrote:

>
> On Dec 20, 2005, at 6:25 AM, Tom Callahan wrote:
>
>> First off, this will void your support contract.
But to get the kernel
>> sources, read the RHEL4 release notes available on
redhat's site.
>>
>> As far as your tape changer issue, verify that sg5
is indeed your
>> changer and not an individual tape device. Once you
have verified  that,
>> create a symlink /dev/changer -> /dev/sg5
>>
>> `mtx status` should then show you stats about your
changer.
>
>
> The problem is that both robot and changer are set to
/dev/sg5 - the 
> device uses different LUNs to distinguish and RHEL is
set up to not 
> scan for different LUNs per SCSI device by default :-(
>
> I get an ok response from the command:
>
>     mtx -f /dev/sg5 inquiry
>
> ... but
>
>     mtx -f /dev/sg5 status
>
> ... fails miserably.
>
>> NOTE: /dev/st0 will rewind the tape after each
write, /dev/nst0 will
>> not, I recommend if using a tape for backup, that
you use /dev/ nst0,
>> and
>> then manually issue a rewind at the end of the
backup functions. This
>> prevents you from inadvertantly overwriting
previously backup up data.
>
>
> Yeah, I know - the tape is ~400GB (an Ultrium-3), so
the backup 
> (~250GB) fits on fine, and there are 8 tapes in the
device. At the 
> moment, the service people are using the front-panel
controls to 
> manually switch tapes on a day-by-day basis. This gives
us a rolling 
> backup for a week. When I get the tape robot working
properly, I'll 
> start writing scripts to do both full and incremental
backups and 
> load/unload tapes on-demand...
>
> A new (clone) server will appear in the next few days,
so I'm going 
> to wait until that arrives before fiddling with kernel
parameters 
> (I'd rather test hardware on the machine that *isn't*
serving a few 
> hundred websites [grin])
>
> Thanks for the help though 
>
> ATB,
>     Simon
>  
>

-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-requestredhat.com?subject=unsubscribe
h
ttps://www.redhat.com/mailman/listinfo/redhat-list

On Dec 21, 2005, at 7:53 AM, Tom Callahan wrote:

> Very strange.... How many drives are in your robot? The
changer itself
> is not really a device that would be seen by a scsi lun
probe, you
> should see three luns if you have 2 drives for
instance.

Just the one drive, 8 slots for tapes - it's an ADIC
FastStor2  
(http://www.adic.com/ibeCCtpItmDspRte.jsp
?section=10030&item=121900#2)

> We have an HP MSL5026 here, along with a 5052, and with
the 5026, I  
> see
> the robot as /dev/sg1 and the drives individually as
/dev/sg2, and  
> sg3.
>
> The 5052 is the same way, but two more drives as
/dev/sg4 and sg5

It's been suggested on the mtx-general list that some robots
(eg:  
mine 
can appear as the same device-id but a different LUN. To get
 
the different sg devices, I expect Matt & Nigel (see the
thread) are  
correct, and I have to have "options scsi_mod
max_luns=32" (or some  
other number >1) in /etc/modprobe.conf. The only devices
I can see  
are all LUN=0...

I'm just waiting until I have a non-live server before I
start  
messing with the SCSI subsystem parameters, since everything
is SCSI  
on the machine, and I don't want to inadvertently do
something which  
changes the SCSI mappings...

> What brand/model of robot are you using, and if
possible, can you give
> me the output of lssg (part of fibreutils package) or
/proc/scsi/ 
> scsi??

I don't have lssg, but /proc/scsi/scsi is:

[rootwww4 ~]$ cat /proc/scsi/scsi
Attached devices:
Host: scsi1 Channel: 00 Id: 00 Lun: 00
   Vendor: IBM-ESXS Model: MAP3735NC     FN Rev: C101
   Type:   Direct-Access                    ANSI SCSI
revision: 03
Host: scsi1 Channel: 00 Id: 01 Lun: 00
   Vendor: IBM-ESXS Model: VPR073C3-ETS10FN Rev: S370
   Type:   Direct-Access                    ANSI SCSI
revision: 04
Host: scsi1 Channel: 00 Id: 08 Lun: 00
   Vendor: IBM      Model: 39M6750a S320  0 Rev: 1
   Type:   Processor                        ANSI SCSI
revision: 02
Host: scsi2 Channel: 00 Id: 00 Lun: 00
   Vendor: IBM      Model: SERVERAID        Rev: 1.00
   Type:   Direct-Access                    ANSI SCSI
revision: 02
Host: scsi2 Channel: 00 Id: 15 Lun: 00
   Vendor: IBM      Model: SERVERAID        Rev: 1.00
   Type:   Processor                        ANSI SCSI
revision: 02
Host: scsi2 Channel: 01 Id: 05 Lun: 00
   Vendor: HP       Model: Ultrium 3-SCSI   Rev: G37B
   Type:   Sequential-Access                ANSI SCSI
revision: 03
Host: scsi2 Channel: 02 Id: 15 Lun: 00
   Vendor: IBM      Model: EXP400   S320    Rev: D110
   Type:   Processor                        ANSI SCSI
revision: 03

> I'm pretty sure this should work out of the box. I've
never had  
> problems
> otherwise.....

[sigh] Whenever a colleague has a bug in software, I walk
over and it  
magically fixes itself. When I come into contact with
hardware,  
anything that can go wrong, does. Maybe the universe is
giving me a  
not-so-subtle hint - stick to software 

Thanks for the help 

ATB,
	Simon

-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-requestredhat.com?subject=unsubscribe
h
ttps://www.redhat.com/mailman/listinfo/redhat-list

I have a server firewall we developed using RHL Fedora Core
3.  It protects
our servers and also itself (since the server also serves as
a PHP web
server).  Our workstations are on a separate network, and I
wanted to know
what port scanner software (free, and windows application)
or tests I can do
to ensure the firewall is indeed protecting our servers from
DoS and
whatnot.  

 
Robert Williams
Programmer / Web Developer / Network Administrator
Covenant Data Systems, Inc.
http://www.covenantdata.c
om
rwilliamscovenantdata.com  
 


-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-requestredhat.com?subject=unsubscribe
h
ttps://www.redhat.com/mailman/listinfo/redhat-list