m1ari: that was it. Q35 chipset. Of course, the Q35 doesn't support IDE, so I had to change the optical drive to sata.

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

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.

spicywolf: 'apropos virtio' gives me the feeling it supposed to be supported.

I'll look at it when I'm done building the gate.

I'm normally on SmartOS, but thought omnios would be easier to use to build the vanilla gate. Simpler and more straight forward.

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.

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).

This method served me well in the past, and I'd like to share with anyone who might have the same need here: paste.omnios.org/?34b8374428ed6e8d#…WuLAWFHRUEyB6eVNPd1PZTM41KHHjckPnfD

In FreeBSD this script was designed to integrate with periodic(8), while in OmniOS is supposed to be launched by cron(8).

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! :)

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.

my script then created a zfs snapshot of the hosts backup directory after the rsync was complete.

for added security, if you're ssh'ing to a host as root is to set PermitRootLogin to forced-commands-only

then you can specify the allowed command(s) along with the allowed public key in the relevant authorized_keys file.

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

become a bridgehead to attack any backed-up production host.

it's a great idea to restrict commands on the backup host, essentially I think that only rsync should be allowed, right?

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

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)

Thanks, I didn't know rrsync. Until now, I only put the "restrict" option in front of authorized SSH keys.

I played a bit with rrsync, and it looks awesome, thank you very much m1ari !

Is there a guide for using ccache while building the gate on omnios?

Or is ccache already on by default?

Asking because I'd really like to not have to full build every time when it costs 2hr15m...

Oh I can include -i on the nightly for it, too. That'll speed up builds a lot in addition.