[asterisk-users] Voicemail and remote directory with SSHFS

[Elliot Murdock]

Hello,

The voicemails are sent over to an independent server to save server
resources (harddisk writing, harddisk space, etc.) and allocate more
bandwidth to live RTP calls.  The servers are located in different
locations, with each one having an independent public IP address.

Accordingly, I need to mount the voicemail directory on both servers.

Thanks,
Elliot




On Fri, May 22, 2009 at 3:32 PM, Jeff LaCoursiere <jeff at jeff.net> wrote:

>
> Lets start from the beginning.  Why are using a network share for your
> voicemail in the first place?
>
> j
>
> On Fri, 22 May 2009, Elliot Murdock wrote:
>
> > Hello Matt,
> >
> > I do agree with you that NFS is that UNIX standard for network
> > filesystems and that what should essentially be used.  However, I
> > shied away from using it, because on the surface it looks too
> > complicated to secure properly.  It uses many ports, dynamic ports,
> > different background daemons, etc.  As I stated before, to mount one
> > or two directories, it is just not worth the trouble to set up a NFS
> > filesystem.  Accordingly, I figured I would go from bottom up,
> > starting with sshfs, samba (which uses only 445 and 139,
> > straightforward config file), and then if those don't work out go
> > through the trouble of setting up a NFS filesystem.
> >
> > If you know of any documents that simplify the NFS (not just how to
> > set up a simple mount, but a full tutorial that describes how it works
> > and how to fully secure it), then I would be more than happy to
> > implement it.
> >
> > Later,
> > Elliot
> >
> > On 5/21/09, Matt Watson <matt at mattgwatson.ca> wrote:
> >> Not that I;m exactly a big fan of NFS but... why would you choose to
> >> implement a filesystem that was designed to emulate Windows shares for
> your
> >> UNIX-type environment?  You have to kind of expect odd problems like
> this
> >> when you choose to use things for other than their intended purpose.
>  Samba
> >> I would say is probably alot more focused on providing storage shares
> for
> >> Windows desktop clients, not for UNIX-type clients.  Sure there is some
> >> support to do what you want, but just keep in mind that similiar to
> using
> >> sshfs like you were trying before, Samba, was really not designed to be
> used
> >> by UNIX clients.  You've already found the most obvious reason... case
> >> sensative filenames - which Windows does not support, and UNIX programs
> >> expect filesystems on your UNIX machine *will* support it.
> >>
> >> That seems kind of like me deciding to use ntfs on a local partition on
> >> linux box instead of ext3/4, jfs, reiserfs, etc.
> >>
> >> --
> >> Matt
> >>
> >> On Thu, May 21, 2009 at 5:06 AM, Elliot Murdock <murdocke at gmail.com>
> wrote:
> >>
> >>> Hello!
> >>>
> >>> Thanks...I set up a Samba mount, which works ok, except that Asterisk
> >>> confuses a wave file as a wav49 file.  I think it may have something do
> >>> with
> >>> the way Samba supports case sensitivity.  Since Windows is not very
> >>> aggressive when it comes to being case sensitive, I am thinking that
> Samba
> >>> is saving files with the last three characters, wav, as uppercase, WAV.
> >>>
> >>> What is the procedure to ensure all the files are saved as is in Samba?
> >>>
> >>> Thanks,
> >>> Elliot
> >>>
> >>>
> >>> On Thu, May 14, 2009 at 5:12 PM, Tilghman Lesher <
> >>> tilghman at mail.jeffandtilghman.com> wrote:
> >>>
> >>>> On Thursday 14 May 2009 08:14:17 Elliot Murdock wrote:
> >>>>> The problem is a file locking problem that Asterisk needs to make
> >>>> changes
> >>>>> to the directory.  I was initially shying away from NFS and Samba,
> >>>> because
> >>>>> I prefer to avoid any sort of security issues with only remotely
> >>>> mounting
> >>>>> one or two directories.  NFS and Samba are designed for larger
> >>>>> applications, which makes those types of technology worthwhile.
> >>>>
> >>>> No, they're both designed as filesystems, which makes typical things
> like
> >>>> locking possible.  SSH is designed as a communications medium, and
> >>>> someone
> >>>> has hacked filesystem support on top of it (poorly, apparently).
>  SSHFS
> >>>> was
> >>>> never designed to be used in server production environments and should
> >>>> not
> >>>> be used there.
> >>>>
> >>>>> I am wondering if there is any way to disable Asterisk's request to
> >>>>> lock
> >>>>> the directory.  I know this may cause some loss in data, but for the
> >>>> volume
> >>>>> voicemail receives, it should be rare enough that would make this
> >>>> approach
> >>>>> an option.
> >>>>
> >>>> There is not.  Use a real filesystem that supports file locking (or
> >>>> really,
> >>>> file linking, which is how the locking is implemented) procedures.
> >>>>
> >>>> --
> >>>> Tilghman
> >>>>
> >>>> _______________________________________________
> >>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >>>>
> >>>> asterisk-users mailing list
> >>>> To UNSUBSCRIBE or update options visit:
> >>>>   http://lists.digium.com/mailman/listinfo/asterisk-users
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >>>
> >>> asterisk-users mailing list
> >>> To UNSUBSCRIBE or update options visit:
> >>>   http://lists.digium.com/mailman/listinfo/asterisk-users
> >>>
> >>
> >
> > _______________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >
> > asterisk-users mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-users
> >
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090524/93bcdebc/attachment.htm