You guys have pockets full of jewels 
...and I love Expect, have put auto expect into practice yet? ...two more interesting perspectives, thanks guys. Wonder if I locate the expect scripts I wrote back in the mid 90s for the old Netranger IDS product that would log into Cisco routers and firewalls to place IP shuns on those firing attack signatures. Can't help but laugh, IDS/IPS has come such a long way since. The sniffer challenge of sucking 100% of the packets off the wire for attack signature examination in a timely manner when we made the 100mb to 1000mb leap was fun.
This is off topic, but I just finished a boot bash script making use of vultrs cloud inftrastructure. If anyone is interested, I'll post them in another thread. A couple of clicks, walk away and come back in 10 minutes and you've got as many as you want fully provisioned PBX nodes running ( FusionPBX, FS, Postgres BDR Master/Slave joined, s3fs fstab mounts ready, ipset additions to iptables, fail2ban, keepalived, bird and BGP failover ). Last few items, I'm doing away with BDRing the FS db as well as doing away with using Resilio sync aka btsync for hotsyncing recs, faxes, vms, etc between block storages and going with a Wireguard and rsync hybrid syncing mashup. I've been using Wireguard for some time now for lots of other requirements, absolutely love it.
@KonradSC , I think I'm going to go ahead and tunnel hot sync to off-FS block and s3 and see just how well/poorly s3 handles postgres queries. I'm wanting CDRs to be able to support containing recordings links off-FS and want to treat the data as time-series type (not queried very often, or only when needed), years archival if need be. I'm currently storing CDRs in XML format in the db, which is local to each FS/Fusion instance, Fusion and (not much longer FS) dbs being synced via BDR. Scratching my head on a best practice of getting the CDRs and recs to off switches block and s3 type storage and making it queriable using the Fusion CDR app. I personally don't like storing blob data types in dbs from past performance experiences so I'm definitely keeping vms and faxes out of it (their migration will be straight forward) - its the CDRs that giving me pause. I think I want them in the db... Don't think I can BDR them, maybe pg_query them out locally, then rsync and delete source ... once at destination, import into db? Sounds like too many cogs in a wheel. Maybe just have FS fire the CDRs directly off switch via tunnel into the remote db? Should I be concerned with losing any CDR data this way or data curruption due to a possible packet loss case? Fun challenges...
Changing gears and focus to an Openfire XMPP and SIP integration via FS ESI project for rest of today. PS anyone know a quick and dirty way of exporting just company config data out of fusion and imported into new instances not on the same networks? Will there be issues doing this if UUIDs have already been applied? Cheers
...and I love Expect, have put auto expect into practice yet? ...two more interesting perspectives, thanks guys. Wonder if I locate the expect scripts I wrote back in the mid 90s for the old Netranger IDS product that would log into Cisco routers and firewalls to place IP shuns on those firing attack signatures. Can't help but laugh, IDS/IPS has come such a long way since. The sniffer challenge of sucking 100% of the packets off the wire for attack signature examination in a timely manner when we made the 100mb to 1000mb leap was fun.This is off topic, but I just finished a boot bash script making use of vultrs cloud inftrastructure. If anyone is interested, I'll post them in another thread. A couple of clicks, walk away and come back in 10 minutes and you've got as many as you want fully provisioned PBX nodes running ( FusionPBX, FS, Postgres BDR Master/Slave joined, s3fs fstab mounts ready, ipset additions to iptables, fail2ban, keepalived, bird and BGP failover ). Last few items, I'm doing away with BDRing the FS db as well as doing away with using Resilio sync aka btsync for hotsyncing recs, faxes, vms, etc between block storages and going with a Wireguard and rsync hybrid syncing mashup. I've been using Wireguard for some time now for lots of other requirements, absolutely love it.
@KonradSC , I think I'm going to go ahead and tunnel hot sync to off-FS block and s3 and see just how well/poorly s3 handles postgres queries. I'm wanting CDRs to be able to support containing recordings links off-FS and want to treat the data as time-series type (not queried very often, or only when needed), years archival if need be. I'm currently storing CDRs in XML format in the db, which is local to each FS/Fusion instance, Fusion and (not much longer FS) dbs being synced via BDR. Scratching my head on a best practice of getting the CDRs and recs to off switches block and s3 type storage and making it queriable using the Fusion CDR app. I personally don't like storing blob data types in dbs from past performance experiences so I'm definitely keeping vms and faxes out of it (their migration will be straight forward) - its the CDRs that giving me pause. I think I want them in the db... Don't think I can BDR them, maybe pg_query them out locally, then rsync and delete source ... once at destination, import into db? Sounds like too many cogs in a wheel. Maybe just have FS fire the CDRs directly off switch via tunnel into the remote db? Should I be concerned with losing any CDR data this way or data curruption due to a possible packet loss case? Fun challenges...
Changing gears and focus to an Openfire XMPP and SIP integration via FS ESI project for rest of today. PS anyone know a quick and dirty way of exporting just company config data out of fusion and imported into new instances not on the same networks? Will there be issues doing this if UUIDs have already been applied? Cheers