sciurus's questions

I replaced a failed battery in a Perc 5/i. The original and replacements are the same DLU8735 model. I couldn't find any special battery replacement procedures in the manual, so I just turned the system off and swapped them. After installing the replacement battery, GetBbuStatus started showing the battery as missing. GetBbuCapacityInfo showed it as charging, so I though perhaps this needed to complete before the battery would be used. However, it is now 100% charged yet still reported as missing. I thought perhaps I need to force a learn cycle, but this completes instantly with no change in status. The system is out of warranty, so I can't call Dell. Any ideas for why this battery is seen yet not used?

lspci | grep RAID

02:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 5

MegaCli64 -AdpBbuCmd -BbuLearn -aALL

Adapter 0: BBU Learn Succeeded.

Exit Code: 0x00

MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL

 BBU status for Adapter: 0

 BatteryType: No Battery
 Battery State: Missing

 Exit Code: 0x00

MegaCli64 -AdpBbuCmd -GetBbuCapacityInfo -aALL

 BBU Capacity Info for Adapter: 0

   Relative State of Charge: 100 %
   Absolute State of charge: 100 %
   Remaining Capacity: 1897 mAh
   Full Charge Capacity: 1900 mAh
   Run time to empty: Battery is not being charged.  
   Average time to empty: Battery is not being charged.  
   Estimated Time to full recharge: Battery is not being charged.  
   Cycle Count: 0
 Max Error = 0 %
 Remaining Capacity Alarm = 190 mAh
 Remining Time Alarm = 10 Min

 Exit Code: 0x00

MegaCli64 -AdpBbuCmd -GetBbuDesignInfo -aALL

 BBU Design Info for Adapter: 0

   Date of Manufacture: 11/15, 2007
   Design Capacity: 1900 mAh
   Design Voltage: 3700 mV
   Specification Info: 49
   Serial Number: 4471
   Pack Stat Configuration: 0xe4bc
   Manufacture Name: SANYO
   Firmware Version   : 
   Device Name: DLU8735
   Device Chemistry: LION
   Battery FRU: N/A
   Transparent Learn = 0
   App Data = 0

 Exit Code: 0x00

MegaCli64 -AdpBbuCmd -GetBbuProperties -aALL

 BBU Properties for Adapter: 0

   Auto Learn Period: 90 Days
   Next Learn time: Sat Jan  1 00:00:00 2000
   Learn Delay Interval:0 Hours
   Auto-Learn Mode: Enabled

 Exit Code: 0x00

I have a system where MegaCli64 -PdList -a0 shows media errors on one disk. After investigating the errors, I've decided not to take any action for now. I'd like to reset the error count, so that MegaCli will show 0 media errors unless there is another error. What arguments to MegaCLI do I need to do this?

Does giving a non-root user ownership of a filesytem have any security implications?

For example, the directory /var/lib/pgsql/9.0/data and its contents needs to be owned by the postgres user. If I want to put its contents on its own filesystem, is it good practice to

• mount that filesystem directly on /var/lib/pgsql/9.0/data

or

• create a directory that is owned by root (such as /mnt/pgsql_data), mount the filesystem there, create a directory owned by postgres on that filesystem (such as /mnt/pgsql_data/data) and make /var/lib/pgsql/9.0/data a symlink to that directory

The only potential security problem I can see with the former is that it gives the postgres user the ability to alter the lost+found directory (if it is an ext2, ext3, or ext4 filesystem), but I don't think this has serious implications.

What motivated me to ask this question is that creating a postgres database isn't supported if a filesystem is mounted on the data directory; see this pgsql-hackers discussion. I hadn't considered the first point of that post before.

I have a server with multiple interfaces and IP addresses on the same network. I would like for non-iSCSI traffic to exclusively use one of the interfaces, and for iSCSI traffic to exclusively use the rest of the interfaces. Limiting the iSCSI traffic to a subset of my interfaces is easy; I simply don't create entries in /var/lib/iscsi/ifaces/ for the interfaces I don't want it to use. However, I'm not sure what is a good approach to limiting the non-ISCSI traffic to one interface. As far as linux is concerned, the iSCSI and non-iSCSI interfaces are equally good routes to the network.

Here's an example configuration

The iSCSI storage has the IP addresses 172.16.50.70-78.

The server has the following interfaces, addresses, and routes.

$ ip route list
149.76.12.0/24 dev eth0  proto kernel  scope link  src 149.76.12.4
172.16.0.0/16 dev eth1  proto kernel  scope link  src 172.16.50.80 
172.16.0.0/16 dev eth2  proto kernel  scope link  src 172.16.50.81 
172.16.0.0/16 dev eth3  proto kernel  scope link  src 172.16.50.82
default via 149.76.12.1 dev eth0

The desired configuration is for eth3 to be used for non-ISCSI traffic and for eth1 and eth2 to be used for iSCSI traffic. However, non-iSCSI traffic currently goes out eth1.

$ ip route get to 172.16.50.90
172.16.50.90 dev eth1  src 172.16.50.80

(some edits since original posting below)

With my current configuration, if eth1 and eth2 are fully saturated sending iSCSI traffic, my non-iSCSI traffic will compete with the iSCSI traffic on eth1 while eth3 sits idle.

How could I configure linux to prefer to send traffic to the local network using eth3 rather than eth1 or eth2?

I have already set net.ipv4.conf.all.arp_ignore to 1 and net.ipv4.conf.all.arp_announce to 2. This should prevent my IP addresses from floating between the interfaces, e.g. arp flux. I think I just need help with the routing.

(more edits)

Thanks to pfo I started looking at metrics. If I delete the routes and recreate them with the iSCSI interfaces having a higher metric than the non-iSCSI interface, things seem to work the way I want. iSCSI traffic still uses the dedicated interfaces without me setting up static routes to the iSCSI IP addresses. All other local traffic goes out eth3. Now I need to figure out the proper way to set the metrics automatically when the interfaces are brought up. This is on RHEL 5.5.

ip route delete to 172.16.0.0/16 dev eth1
ip route delete to 172.16.0.0/16 dev eth2
ip route delete to 172.16.0.0/16 dev eth3
ip route add to 172.16.0.0/16 dev eth1 src 172.16.50.80 metric 1
ip route add to 172.16.0.0/16 dev eth2 src 172.16.50.81 metric 1
ip route add to 172.16.0.0/16 dev eth3 src 172.16.50.82 metric 0

(final update)

Assigning a different metric using the existing RHEL network scripts seems impossible, https://bugzilla.redhat.com/show_bug.cgi?id=498472