smartd, mfi, SAS and SATA

2019-11-20 Thread O'Connor, Daniel
Hi everyone,
I recently took delivery of a Supermicro X11SRM-F with a Broadcom MegaRAID 
9361-8i SAS 8 port card which has 4 Intel D3-S4610 960 GB SSDs and 4 Hitachi/WD 
Ultrastar HC300 4TB drives each in a RAID5.

I have /usr/local/etc/smartd.conf with just 'DEVICESCAN' and when smartd starts 
I see..
Nov 21 01:17:49 maarsy-acq3 smartd[2103]: Opened configuration file 
/usr/local/etc/smartd.conf
Nov 21 01:17:49 maarsy-acq3 smartd[2103]: Drive: DEVICESCAN, implied '-a' 
Directive on line 23 of file /usr/local/etc/smartd.conf
Nov 21 01:17:49 maarsy-acq3 smartd[2103]: Configuration file 
/usr/local/etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Nov 21 01:17:49 maarsy-acq3 smartd[2103]: Device: /dev/pass0, opened
Nov 21 01:17:49 maarsy-acq3 smartd[2103]: Device: /dev/pass0, [HGST 
HUS726T4TAL5204  C40H], lu id: 0x5000cca097502308, S/N: V6HE27MR, 4.00 TB
Nov 21 01:17:50 maarsy-acq3 smartd[2103]: Device: /dev/pass0, is SMART capable. 
Adding to "monitor" list.
Nov 21 01:17:50 maarsy-acq3 smartd[2103]: Device: /dev/pass1, opened
Nov 21 01:17:50 maarsy-acq3 smartd[2103]: Device: /dev/pass1, [HGST 
HUS726T4TAL5204  C40H], lu id: 0x5000cca09751d2c8, S/N: V6HEZZZR, 4.00 TB
Nov 21 01:17:50 maarsy-acq3 smartd[2103]: Device: /dev/pass1, is SMART capable. 
Adding to "monitor" list.
Nov 21 01:17:50 maarsy-acq3 smartd[2103]: Device: /dev/pass2, opened
Nov 21 01:17:50 maarsy-acq3 smartd[2103]: Device: /dev/pass2, [HGST 
HUS726T4TAL5204  C40H], lu id: 0x5000cca097509ad8, S/N: V6HEA6ZR, 4.00 TB
Nov 21 01:17:51 maarsy-acq3 smartd[2103]: Device: /dev/pass2, is SMART capable. 
Adding to "monitor" list.
Nov 21 01:17:51 maarsy-acq3 smartd[2103]: Device: /dev/pass3, opened
Nov 21 01:17:51 maarsy-acq3 smartd[2103]: Device: /dev/pass3, [HGST 
HUS726T4TAL5204  C40H], lu id: 0x5000cca0974f1630, S/N: V6HDHALR, 4.00 TB
Nov 21 01:17:51 maarsy-acq3 smartd[2103]: Device: /dev/pass3, is SMART capable. 
Adding to "monitor" list.
Nov 21 01:17:51 maarsy-acq3 smartd[2103]: Device: /dev/pass4, type changed from 
'scsi' to 'sat'
Nov 21 01:17:51 maarsy-acq3 smartd[2103]: Device: /dev/pass5, type changed from 
'scsi' to 'sat'
Nov 21 01:17:51 maarsy-acq3 smartd[2103]: Device: /dev/pass6, type changed from 
'scsi' to 'sat'
Nov 21 01:17:52 maarsy-acq3 smartd[2103]: Device: /dev/pass7, type changed from 
'scsi' to 'sat'
Nov 21 01:17:52 maarsy-acq3 smartd[2103]: Monitoring 0 ATA/SATA, 4 SCSI/SAS and 
0 NVMe devices
Nov 21 01:17:53 maarsy-acq3 smartd[2105]: smartd has fork()ed into background 
mode. New PID=2105.
Nov 21 01:17:53 maarsy-acq3 smartd[2105]: file /var/run/smartd.pid written 
containing PID 2105

So it is monitoring the SAS disks but has ignored the SATA SSDs :(

[maarsy-acq3 1:33] ~> camcontrol devlist
at scbus8 target 8 lun 0 (pass0)
at scbus8 target 9 lun 0 (pass1)
at scbus8 target 10 lun 0 (pass2)
at scbus8 target 11 lun 0 (pass3)
at scbus8 target 12 lun 0 (pass4)
at scbus8 target 13 lun 0 (pass5)
at scbus8 target 14 lun 0 (pass6)
at scbus8 target 15 lun 0 (pass7)
 at scbus9 target 0 lun 0 (da0,pass8)

If I run smartctl on an SSD I get..
[maarsy-acq3 1:33] ~> sudo smartctl -a /dev/pass4|less
smartctl 7.0 2018-12-30 r4883 [FreeBSD 12.0-RELEASE amd64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

Smartctl open device: /dev/pass4 [SAT] failed: SATA device detected,
MegaRAID SAT layer is reportedly buggy, use '-d sat' to try anyhow

And using what it suggests seems to work - does anyone know a way to force it 
to work with DEVICESCAN?

For now I've just hard coded it like so..
DEFAULT -m root
/dev/pass0
/dev/pass1
/dev/pass2
/dev/pass3
/dev/pass4 -d sat
/dev/pass5 -d sat
/dev/pass6 -d sat
/dev/pass7 -d sat

but it seems clunky.. also I see these slightly puzzling messages for each SSD..
Nov 21 01:37:08 maarsy-acq3 smartd[3656]: Device: /dev/pass4 [SAT], opened
Nov 21 01:37:08 maarsy-acq3 smartd[3656]: Device: /dev/pass4 [SAT], INTEL 
SSDSC2KB960G8, S/N:PHYF92630636960CGN, WWN:5-5cd2e4-150f430c3, FW:XCV10120, 960 
GB
Nov 21 01:37:08 maarsy-acq3 smartd[3656]: Device: /dev/pass4 [SAT], found in 
smartd database: Intel S4510/S4610/S4500/S4600 Series SSDs
Nov 21 01:37:08 maarsy-acq3 smartd[3656]: Device: /dev/pass4 [SAT], not capable 
of SMART Health Status check
Nov 21 01:37:08 maarsy-acq3 smartd[3656]: Device: /dev/pass4 [SAT], can't 
monitor Offline_Uncorrectable count - no Attribute 198
Nov 21 01:37:08 maarsy-acq3 smartd[3656]: Device: /dev/pass4 [SAT], is SMART 
capable. Adding to "monitor" list.

Which I am hoping aren't anything to worry about..

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


12.0->12.1 and beadm/bectl issues

2019-11-20 Thread Jon Tibble via freebsd-stable

Hi,

After upgrading from 12.0-RELEASE-p11 to 12.1-RELEASE I was having some 
issues with kld_load and linux support which, after searching [1], 
seemed due to a missing /boot folder after the upgrade.

This was fixed with 'ln -s /bootpool/boot /boot'.

Then yesterday when I was trying to switch from quarterly packages to 
latest I wanted to use a new boot environment and so went through the 
beadm create and beadm activate but it wouldn't activate with a 
zpool.cache cp message and it left the new BE mounted under /tmp.
After umounting and destroying I repeated the process with bectl and it 
worked fine, however, upon reboot I was not in the new BE but the same 
BE and the new one was still marked as activated for use next boot.


So firstly: are the be* issues related to the earlier upgrade fix?

Secondly: shouldn't beadm and bectl behave the same?

Thirdly: how can I properly activate and boot to a new BE?

Below is the command output of the beadm/bectl process described above. 
If there's any more information I can provide please let me know.


Thanks,
Jon

[1] 
https://forums.freebsd.org/threads/cannot-identify-running-kernel-after-upgrading-to-freebsd-12.68772/



This is a two disk mirrored zpool on GELI with encrypted swap as 
configured out of the box by the 12.0 installer.


root@prometheus:~ # uname -a
FreeBSD prometheus 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64
root@prometheus:~ # beadm list
BEActive Mountpoint  Space Created
12_0-RELEASE-p11  -  -1.1G 2019-10-29 21:33
12_1-RELEASE-p1-quarterly NR /   32.7G 2019-11-05 22:24
root@prometheus:~ # beadm create test
Created successfully
root@prometheus:~ # beadm list
BEActive Mountpoint  Space Created
12_0-RELEASE-p11  -  -1.1G 2019-10-29 21:33
12_1-RELEASE-p1-quarterly NR /   32.7G 2019-11-05 22:24
test  -  -8.0K 2019-11-20 13:24
root@prometheus:~ # beadm activate test
cp: /tmp/BE-test.pJtR9Rs6/boot/zfs/zpool.cache and /boot/zfs/zpool.cache 
are identical (not copied).

root@prometheus:~ # beadm list
BEActive Mountpoint Space Created
12_0-RELEASE-p11  -  -   1.1G 2019-10-29 
21:33
12_1-RELEASE-p1-quarterly NR /  32.7G 2019-11-05 
22:24
test  -  /tmp/BE-test.pJtR9Rs6 136.0K 2019-11-20 
13:24

root@prometheus:~ # beadm umount test
Unmounted successfully
root@prometheus:~ # beadm list
BEActive Mountpoint  Space Created
12_0-RELEASE-p11  -  -1.1G 2019-10-29 21:33
12_1-RELEASE-p1-quarterly NR /   32.7G 2019-11-05 22:24
test  -  -  136.0K 2019-11-20 13:24
root@prometheus:~ # beadm destroy test
Are you sure you want to destroy 'test'?
This action cannot be undone (y/[n]): y
Destroyed successfully
root@prometheus:~ # beadm list
BEActive Mountpoint  Space Created
12_0-RELEASE-p11  -  -1.1G 2019-10-29 21:33
12_1-RELEASE-p1-quarterly NR /   32.7G 2019-11-05 22:24
root@prometheus:~ # bectl list
BEActive Mountpoint Space Created
12_0-RELEASE-p11  -  -  1.14G 2019-10-29 21:33
12_1-RELEASE-p1-quarterly NR /  32.7G 2019-11-05 22:24
root@prometheus:~ # bectl create test
root@prometheus:~ # bectl list
BEActive Mountpoint Space Created
12_0-RELEASE-p11  -  -  1.14G 2019-10-29 21:33
12_1-RELEASE-p1-quarterly NR /  32.7G 2019-11-05 22:24
test  -  -  8K2019-11-20 13:25
root@prometheus:~ # bectl activate test
successfully activated boot environment test
root@prometheus:~ # bectl list
BEActive Mountpoint Space Created
12_0-RELEASE-p11  -  -  1.14G 2019-10-29 21:33
12_1-RELEASE-p1-quarterly N  /  8K2019-11-05 22:24
test  R  -  32.7G 2019-11-20 13:25
root@prometheus:~ # beadm list
BEActive Mountpoint  Space Created
12_0-RELEASE-p11  -  -1.1G 2019-10-29 21:33
12_1-RELEASE-p1-quarterly N  /8.0K 2019-11-05 22:24
test  R  -   32.7G 2019-11-20 13:25
root@prometheus:~ #

Following a reboot I'll still be running in 12_1-RELEASE-p1-quarterly 
and test will still be marked R.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: jexec as user?

2019-11-20 Thread Ronald Klop

Yeah, ssh is also possible. See my original mail :-) 
https://lists.freebsd.org/pipermail/freebsd-stable/2019-November/091742.html

I run my jails with "ip4 = inherit;". So I would need to do some 
port-forwarding trickery with ssh on different ports.
The users already login on the host to do various actions. Jailme gives the 
easiest access without to much maintenance for now.

Regards,
Ronald.

Van: Eugene Grosbein 
Datum: woensdag, 20 november 2019 11:44
Aan: Ronald Klop , Miroslav Lachman <000.f...@quip.cz>
CC: Christos Chatzaras , freebsd-stable 

Onderwerp: Re: jexec as user?


20.11.2019 16:47, Ronald Klop wrote:

> Thanks for all the advice. I am indeed looking for using jail from the 
non-root user in the host. Jailme sounds like a good solution.
>
> My use case is providing a relatively save way of giving a user the 
possibility to experiment with root rights (like creating and installing ports) 
without wracking the host system.
> The users are trusted so it is not so much about security. More about keeping 
the host system clean.

You also could run ssh service inside the jail and give users opportunity to 
experiment with ssh and keys :-)
 





___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: jexec as user?

2019-11-20 Thread Eugene Grosbein
20.11.2019 16:47, Ronald Klop wrote:

> Thanks for all the advice. I am indeed looking for using jail from the 
> non-root user in the host. Jailme sounds like a good solution.
> 
> My use case is providing a relatively save way of giving a user the 
> possibility to experiment with root rights (like creating and installing 
> ports) without wracking the host system.
> The users are trusted so it is not so much about security. More about keeping 
> the host system clean.

You also could run ssh service inside the jail and give users opportunity to 
experiment with ssh and keys :-)

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: jexec as user?

2019-11-20 Thread Ronald Klop

Thanks for all the advice. I am indeed looking for using jail from the non-root 
user in the host. Jailme sounds like a good solution.

My use case is providing a relatively save way of giving a user the possibility 
to experiment with root rights (like creating and installing ports) without 
wracking the host system.
The users are trusted so it is not so much about security. More about keeping 
the host system clean.

Regards,
Ronald.

Van: Miroslav Lachman <000.f...@quip.cz>
Datum: dinsdag, 19 november 2019 20:31
Aan: Christos Chatzaras , freebsd-stable 

CC: Ronald Klop 
Onderwerp: Re: jexec as user?


Christos Chatzaras wrote on 2019/11/19 14:09:
>
>
>> On 19 Nov 2019, at 15:02, mike tancsa  wrote:
>>
>> On 11/19/2019 6:42 AM, Ronald Klop wrote:
>>> Hi,
>>>
>>> Is it possible to jexec into a jail as a regular user. Or to enable
>>> that somewhere?
>>> Or is the way to do such a thing to set up ssh in the jail?
>>>
>> On 11.3 at least, does not the built in functionality of jexec do what
>> you need ?
>>
>> jexec [-l] [-u username | -U username] jail [command ...]
>>
>> # jexec -U testuser 3 csh
>> testuser@cacticonsole:/ % id
>> uid=1005(testuser) gid=1005(testuser) groups=1005(testuser)
>> testuser@cacticonsole:/ %
>>
>
> I think he wants to use jexec as a normal user from the main OS.
>
> If he wants to run jexec as root and login to jail as user then your command 
works.

If you want to use jexec as normal user in host, look at sysutils/jailme from 
ports:

https://www.freshports.org/sysutils/jailme/
This version is installed setuid and does some sanity checking to ensure the 
username and UID match between the jail and the host system.

WWW: https://github.com/Intermedix/jailme

Miroslav Lachman

PS: I never used jailme personally




___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"