03:55:07 m1ari: that was it. Q35 chipset. Of course, the Q35 doesn't support IDE, so I had to change the optical drive to sata. 03:56:31 Oh uh. andyf as well, in case they're spinning on this. Kernel is loaded, even booted full uefi. I'm sitting at the text installer. :D 04:10:23 Does omnios not have virtio drivers on the install media? I mean, I suppose I could have used the cloud image, but like... Had to set the primary disk to sata emulation and the nic to e1000e. 05:27:42 spicywolf: 'apropos virtio' gives me the feeling it supposed to be supported. 05:29:53 I'll look at it when I'm done building the gate. 05:30:53 I'm normally on SmartOS, but thought omnios would be easier to use to build the vanilla gate. Simpler and more straight forward. 14:05:35 Hi to all. I just ported to OmniOS a shell script I made years ago to backup FreeBSD configuration and data to a remote location using rsync(1) over SSH. 14:05:37 I know that a good way for a disaster recovery plan is to remotely zfs send/receive all datasets of a host, but I prefer a slimmer approach in case of catastrophic failure (reinstall the host, then import only relevant config and data from a remote location). 14:05:56 This method served me well in the past, and I'd like to share with anyone who might have the same need here: https://paste.omnios.org/?34b8374428ed6e8d#45wvibxvVWuLAWFHRUEyB6eVNPd1PZTM41KHHjckPnfD 14:06:12 In FreeBSD this script was designed to integrate with periodic(8), while in OmniOS is supposed to be launched by cron(8). 14:06:17 Please also note that I'm a sysadmin and not a developer: writing code is not within my attitudes... so any suggestion/criticism on this solution will be gratefully appreciated! :) 16:14:31 warden: I've done similar in the past, although in that case I ran the script on the backup target and it used rsync/ssh to pull the data from the host to be backed up. 16:15:38 my script then created a zfs snapshot of the hosts backup directory after the rsync was complete. 16:17:10 for added security, if you're ssh'ing to a host as root is to set PermitRootLogin to forced-commands-only 16:18:01 then you can specify the allowed command(s) along with the allowed public key in the relevant authorized_keys file. 16:22:05 m1ari: thanks, I choose to push data instead of pull because of this though: if the production host would be compromised, the attacker could corrupt online backups, but the destination is a FreeBSD jail, protected with immutable ZFS snapshots which cannot be deleted within the jail, while if the backup host could access production data it would 16:22:05 become a bridgehead to attack any backed-up production host. 16:22:59 it's a great idea to restrict commands on the backup host, essentially I think that only rsync should be allowed, right? 16:51:38 I think on most systems rsync includes a script called rrsync (might be gzipped by default) that's designed for the allowed command option in ssh 16:58:28 I think whichever way you do it there's tradeoffs, in my case the backup server was behind a NAT device so harder to access from the clients. It also meant the setup on the hosts I wanted to backup was minimal (configure sshd, setup the /root/.ssh/authorized_keys file was setup properly, install rsync and the rrsync script) 17:04:51 Thanks, I didn't know rrsync. Until now, I only put the "restrict" option in front of authorized SSH keys. 17:53:55 I played a bit with rrsync, and it looks awesome, thank you very much m1ari ! 18:23:36 Is there a guide for using ccache while building the gate on omnios? 18:24:03 Or is ccache already on by default? 18:24:39 Asking because I'd really like to not have to full build every time when it costs 2hr15m... 18:36:49 Oh I can include -i on the nightly for it, too. That'll speed up builds a lot in addition.