Nov 152016
 

I had to migrate one storage server from FreeBSD (NAS4Free to be exact) to Centos Linux 7. Sadly recent NAS4FREE was just too unstable on this particular hardware, f.e. any attempt to change configuration using web interface was causing a reboot with no meaningful message in logs – unacceptable as I rely on it in few of my projects, for example my diskless boot of HP Blades in my Openstack deployment. Shame cause I liked the idea behind it.

Anyway, because I consider now ZFS on Linux production ready I decided to move to Centos 7 – I like Centos more and more, and with version 7 being supported until 2024 I’m getting 8 more years of trouble free ride.

Before deploying new OS I removed log and cache devices from my ZFS pool. What I didn’t do was removing a spare and that bitten me in the, oh you know probably where. When I imported my pool under Centos, spare disk was in status “UNAVAIL”.

# zpool status -v
  pool: tank
 state: ONLINE
  scan: scrub repaired 0 in 2h19m with 0 errors on Tue Nov  1 03:19:26 2016
config:

	NAME                                            STATE     READ WRITE CKSUM
	tank                                            ONLINE       0     0     0
	  raidz3-0                                      ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B3_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B0_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B0_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B0_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B0_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B0_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B0_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B2_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B0_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B0_WD-xxxx  ONLINE       0     0     0
	    ata-WDC_WD4000FYYZ-01UL1B2_WD-xxxx  ONLINE       0     0     0
	spares
	  mfisyspd10                                    UNAVAIL 

errors: No known data errors

Attempt to “zpool remove tank mfisyspd10” was unsuccessful, as zpool was claiming it cannot see this device. D’oh.

Fortunately ZFS comes with zdb, low level utility that can display lots of interesting stuff, if you are into this kind of thing. Most importantly, it can help us to determine numerical ID of the device, ID that can be used to operate on this disk.
By examining content of /dev/disk/by-id/ based on serial numbers I realised that “missing” mfisyspd10 is now called “sdk” under Linux.

zdb -l /dev/sdk # this came back with long numerical ID

zpool remove tank 12658963864105390900 # now phantom should be gone, as confirmed with zpool status -v

# we can re-add it using Linux mechanism

zpool add tank spare -f /dev/disk/by-id/ata-WDC_WD4000FYYZ-01UL1B2_WD-xxxxxxxxx

Done. Now I can re-add cache and log devices, using partitions from my internal SSD drives and start feeding  ZFS pool cache/log data into Check_MK using this script

Feb 102016
 

4x_NvidiaGTX780 GPU

I’ve got Centos 7 based Bacula installation with storage daemon writing to file volumes located on ZFS filesystem. Chown’ing filesystem to user bacula was not enough, SElinux being SElinux didn’t particularly like bacula writing to location chosen by me (/tank/backup) as it expects Bacula to write to /bacula by default.

Lets identify available Bacula contexts and re-label /tank/backup accordingly

# semanage fcontext -l | grep bacula
 /bacula(/.*)? all files system_u:object_r:bacula_store_t:s0
 /etc/bacula.* all files system_u:object_r:bacula_etc_t:s0
 /var/bacula(/.*)? all files system_u:object_r:bacula_store_t:s0
 /var/lib/bacula.* all files system_u:object_r:bacula_var_lib_t:s0
 /var/log/bacula.* all files system_u:object_r:bacula_log_t:s0
 /var/run/bacula.* regular file system_u:object_r:bacula_var_run_t:s0
 /usr/sbin/bacula.* regular file system_u:object_r:bacula_exec_t:s0
 /var/spool/bacula.* all files system_u:object_r:bacula_spool_t:s0
 /var/spool/bacula/log(/.*)? all files system_u:object_r:var_log_t:s0
 /etc/rc\.d/init\.d/bacula.* regular file system_u:object_r:bacula_initrc_exec_t:s0
 /usr/sbin/bat regular file system_u:object_r:bacula_admin_exec_t:s0
 /usr/sbin/bconsole regular file system_u:object_r:bacula_admin_exec_t:s0

Ahh OK, so it’s called “system_u:object_r:bacula_store_t:s0” – lets apply it

chcon system_u:object_r:bacula_store_t:s0 /tank/backup
semanage fcontext -a -t bacula_store_t "/tank/backup(/.*)?"
restorecon -R -v /tank/backup

Same will work if your Centos 7 client will refuse to restore data to /bacula-restores, with message in server log:

26-Sep 14:40 death-star JobId 24822: Error: mkpath.c:138 Cannot create directory /bacula-restores/backup: ERR=Permission denied

and message in client log:

type=AVC msg=audit(1474897201.721:307): avc:  denied  { write } for  pid=26477 comm="bacula-fd" name="bacula-restores" dev="vda1" ino=159551617 scontext=system_u:system_r:bacula_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir

Simply run:

chcon system_u:object_r:bacula_store_t:s0 /bacula-restores
semanage fcontext -a -t bacula_store_t "/bacula-restores(/.*)?"
restorecon -R -v /bacula-restores
ls -lZ /

and now your restore job will run just fine. Magic.