Re: [luv-main] Re: Internode + Nodephone + Asterisk (+FreePBX?)
On 14/06/2016 9:59 AM, Peter Ross wrote: > On Mon, Jun 13, 2016 at 10:29 PM, Andrew McGlashan wrote: > > > Setting up Asterix or FreePBX or anything similar is not something > that > should be done lightly. VoIP providers lose an awful lot of money if > there are any loop holes in their setup; perhaps even just a weak > password. So, it is a serious risk situation, potentially; especially > when there are continual software updates to fix vulnerabilities > in all > kinds of software. > > I'm not saying don't do it, but I am saying that you have to > understand > the risks and perhaps you would be better off not doing it. > > > Hi Andrew, > > can you elaborate a bit about Asterisk/FreePBX security issues? I install Asterisk systems for a VoIP providers and the biggest mistake is allowing any sort of external SIP traffic. Always double check that your router does not auto open a port for the SIP (SIP ALG can do this, I always disable SIP ALG). If remote access is needed use IAX and have a remote install of Asterisk, or in the worst case use a VPN for remote phones. (Yealink phones have a OpenVPN client) Always use a user name which is different from the extension and strong passwords. The packaged versions of Asterisk are generally secure as long as there is no external direct access. Never had a machine hacked or unauthorised calls made if the rules are followed but had a number of them when they where not. Mike ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Photobooth script - needs help with inotify
On 14/06/16 21:08, Andrew Greig via luv-main wrote: > I know that 4 years in Linux is a long time, so I was not surprised to > find that the script failed because the inotifywait command is no longer > recognised. I am not skilled in scripting but I did read the man file. The inotify-tools package is still available on Debian based distros and probably the others (though it may not be installed by default). Glenn -- sks-keyservers.net 0x6d656d65 signature.asc Description: OpenPGP digital signature ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Best Database For Storing Images
have a look at OMERO then. that's what it does - it's a metadata manager.
(fundamentally though, any DB is a front end to a filesystem anyway...-
even if it is it's own "special" FS)
On Tue, Jun 14, 2016 at 4:12 PM, Craig Sanders via luv-main <
luv-main@luv.asn.au> wrote:
> On Mon, Jun 13, 2016 at 06:30:46PM +1000, Andrew McN wrote:
> > On 13/06/16 17:21, James Harper wrote:
> > > https://wiki.postgresql.org/wiki/BinaryFilesInDB
>
> > I find that article unconvincing, but my concerns are mostly around
> > performance. If performance is of no concern at all, then the
> > atomicity/maintenance argument might be significant (though not the
> > stuff about storing as a text data type).
>
> I'm not convinced either. Same as I'm never convinced by the recurring
> idea of using an SQL database as a mail-storage backend.
>
> IMO the best option is to use a database to store information about the
> image (path and filename or URI, size, width, height, geo-location,
> description, and whatever other details are required. Maybe even a
> small thumbnail image), whilst storing the actual image in either:
>
> - a filesystem, with a hashed directory structure to avoid having too
>many files in one directory. e.g.
>
>.../images/{00-ff}/{00-ff}/{00-ff}/imagefile.png
>
>If you're worried about the image pathname getting out of sync with
>the database, you could write your own FUSE fs layered on top of the
>actual fs to automatically update the database if a file is renamed
>or moved.
>
>BTW, there are FUSE modules for perl and python to make this easier
>if you don't want to use C.
>
>
> - An object store like Amazon S3, Openstack's swift, or ceph.
>
>BTW, there are existing FUSE modules for these that could be modified
>to update a database if an object is changed.
>
>
> For a very large number of images, an object store is the best
> option...you get hugely scalable performance, redundancy, and storage
> capacity.
>
> craig
>
> --
> craig sanders
>
> BOFH excuse #302:
>
> microelectronic Riemannian curved-space fault in write-only file system
> ___
> luv-main mailing list
> luv-main@luv.asn.au
> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
>
--
Dr Paul van den Bergen
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Best Database For Storing Images
On Tue, Jun 14, 2016 at 04:12:21PM +1000, Craig Sanders via luv-main wrote: > > IMO the best option is to use a database to store information about > the image [...] whilst storing the actual image in [...] a filesystem, > with a hashed directory structure [...] Agreed. > If you're worried about the image pathname getting out of sync with > the database, you could write your own FUSE fs layered on top of > the actual fs to automatically update the database if a file is > renamed or moved. [...] Rather than writing a FUSE, you could also use one of the inotify(7) tools to set up watches on these directories, see; inotifywait(1), inotifywatch(1) or incrond(8)/incrontab(5) – although that is Linux specific, and you'd need to handle directory tree recursion yourself. ~Joel ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Best Database For Storing Images
On Mon, Jun 13, 2016 at 06:30:46PM +1000, Andrew McN wrote:
> On 13/06/16 17:21, James Harper wrote:
> > https://wiki.postgresql.org/wiki/BinaryFilesInDB
> I find that article unconvincing, but my concerns are mostly around
> performance. If performance is of no concern at all, then the
> atomicity/maintenance argument might be significant (though not the
> stuff about storing as a text data type).
I'm not convinced either. Same as I'm never convinced by the recurring
idea of using an SQL database as a mail-storage backend.
IMO the best option is to use a database to store information about the
image (path and filename or URI, size, width, height, geo-location,
description, and whatever other details are required. Maybe even a
small thumbnail image), whilst storing the actual image in either:
- a filesystem, with a hashed directory structure to avoid having too
many files in one directory. e.g.
.../images/{00-ff}/{00-ff}/{00-ff}/imagefile.png
If you're worried about the image pathname getting out of sync with
the database, you could write your own FUSE fs layered on top of the
actual fs to automatically update the database if a file is renamed
or moved.
BTW, there are FUSE modules for perl and python to make this easier
if you don't want to use C.
- An object store like Amazon S3, Openstack's swift, or ceph.
BTW, there are existing FUSE modules for these that could be modified
to update a database if an object is changed.
For a very large number of images, an object store is the best
option...you get hugely scalable performance, redundancy, and storage
capacity.
craig
--
craig sanders
BOFH excuse #302:
microelectronic Riemannian curved-space fault in write-only file system
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
