Recovering a Linux SW RAID1 volume

I had one disk of a RAID1 set, and wanted to recover the data from some LVMs on it.

Turned out to be quite straightforward:

1. Plugged the drive into another openSUSE 12.1 box with a USB-HDD adapter.

2. As root, did mdadm --assemble --scan

3. 'cat /proc/mdstat' showed me the md devices that were found:Personalities : [linear] [raid1]
md124 : active raid1 sdg1[0]
      506032 blocks super 1.0 [2/1] [U_]
      bitmap: 0/8 pages [0KB], 32KB chunk

md125 : active raid1 sdg2[0]
      155726004 blocks super 1.0 [2/1] [U_]
      bitmap: 19/149 pages [76KB], 512KB chunk

md126 : inactive sdf1[0](S)
      506032 blocks super 1.0
     
md127 : inactive sdf2[0](S)
      155734036 blocks super 1.0
     
unused devices: <none>

4. lvscan showed me the LVs on the volume.
  inactive          '/dev/system1/home' [70.00 GiB] inherit
  inactive          '/dev/system1/lclhome' [30.00 GiB] inherit
  inactive          '/dev/system1/root' [20.00 GiB] inherit
  inactive          '/dev/system1/swap' [4.00 GiB] inherit
  inactive          '/dev/system1/usr' [6.00 GiB] inherit
  ACTIVE            '/dev/system/home' [25.00 GiB] inherit
  ACTIVE            '/dev/system/root' [20.00 GiB] inherit
  ACTIVE            '/dev/system/swap' [2.00 GiB] inherit

5. Activated the LVs using 'vgchange -a y'

6. Ready to mount!

KDE4 and ssh-agent

Using KDE Wallet to store your SSH passphrase is now quite easy.

You need ksshaskpass installed.


Add a script to ~/.kde4/Autostart/ called (e.g.) ssh-add.sh, with execute permission, containing:

#!/bin/sh
export SSH_ASKPASS=/usr/lib64/ssh/ksshaskpass
/usr/bin/ssh-add

Next time you login, you'll be prompted for your KDE Wallet password, then your password.

Works well. Thanks to this helpful post for getting me started.

SanDisk CF card as HDD for embedded PC

Purchased a 16GB SanDisk CF card as upgrade to a 4GB unit, for main drive in embedded PC (IDE-CF interface). First attempt to partition the card showed first available sector as being number 2048. Further research seemed to indicate that this might be a result of consumer and pro grade SanDisk CFs are shipped in "Removable Disk" mode, and I would need to convert it to "Fixed Disk" mode.

I was able to find a SanDisk conversion utility, but this required connecting the card via an IDE adapter and booting to DOS. While waiting for hardware, I tried just using dd to copy the entire drive image to a file; then using
this guide to resize the root partition with fdisk and parted; then dd'd the new image to the new card.

I was surprised to see that the partition table on the newly-loaded card appeared normal (no 2048 sector offset). And it booted fine.

Life is good.

apcupsd with APC SmartUPS and AP9617 using PCNET

Clarifications, based on apcupsd 3.14 and AP9617 FW version 3.7.3:

- The DEVICE password in apcupsd.conf needs to match the "Authentication Phrase" in UPS->PowerChute->configuration

- The IP address of the host that is running apcupsd must be added to "PowerChute Network Shutdown Clients" in UPS->PowerChute->clients

- I have two SmartUPSs, one feeding each redundant power supply. I used the multiple UPS Example in the manual, but did not null-configure the shutdown scripts, so that either UPS failing would initiate a shutdown. Unfortunately, it seems the PCNET port number cannot be changed, and both apcupsd instances want to bind it.

multilog patch update for daemontools

I found this useful patch to provide human-readable dates for daemontools multilog:

http://blog.endersys.com/2009/12/qmail-multilog-localtime-patch-for-daemontools-0-76/

Unfortunately, the time format that was chosen is not useful for navigating lengthy logfiles.

Here's my version that uses ISO-8601 date format.

Dell OMSA: how to enable SNMP on openSUSE

Quite easy for openSUSE 11.3 . The only modification to normal procedure is to replace this line in /etc/snmp/snmpd.conf :

#rocommunity public 127.0.0.1

rocommunity public

Dell OMSA: how to enable SNMP on Debian

This worked for me with Debian Lenny on a PE 2900. Reposting, since it took a bit of digging to find it. Credit to Bas Roos

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

* apt-get install snmpd

* Edit /etc/snmp/snmpd.conf

- Comment out 'com2sec paranoid default public

- Uncomment out '#com2sec readonly default public'

- Change 'default' into our management IP range in the previous

step (resulting in 'com2sec readonly 192.168.2.0/24 public')

* Edit /etc/default/snmpd

- Change SNMPDOPTS

- Before: SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux

-p /var/run/snmpd.pid 127.0.0.1'

- After: SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -p

/var/run/snmpd.pid 0.0.0.0' (this enabled smux and made snmpd listen on

all interfaces, instead of lo)

* /etc/init.d/dataeng enablesnmp (this should enable SNMP for both dataeng

itself, as it adds a line to /etc/snmp/snmpd.conf)

* /etc/init.d/dataeng restart (restarts dataeng and starts dsm_sa_snmp32d)

* /etc/init.d/snmpd restart

After this, SNMP seems to be working:

username at mgmt-server:~$ snmpwalk -v 2c -c public 192.168.2.71

.1.3.6.1.4.1.674.10892.1.300.10.1.11.1

SNMPv2-SMI::enterprises.674.10892.1.300.10.1.11.1 = STRING: "

here>"