Virtualization server automatic CIFS file system mount point

[sacco]

What does 'automatic' mean in this context?

In the config file it says:

# Virtualization server automatic CIFS file system mount point
#
#     The virtualization server can expose the remote
#     Alfresco AVM repository as a CIFS file system.
#     The properties below specify where (and whether)
#     this automatic mount takes place on Windows
#     and on UNIX-based systems (e.g.: Linux, Mac).
#‍‍‍‍‍‍‍‍

To me, having a setting

alfresco.virtserver.cifs.avm.versiontree.unix.automount=true‍

implies that Alfresco should (according to this setting) automatically take care of
mounting the AVM filesystem after it has started, but this does not yet seem
to be the case.

I can mount the AVM file-system manually, and I could include this mount in the Alfresco start-up scripts
(though I guess it would probably need to wait or retry in some way),
and I can see that by setting

alfresco.virtserver.cifs.avm.versiontree.unix=/srv/alfresco/cifs_2.1-a/AVM‍

I might make the AVM filesystem available to applets (rather than going through JNDI),
but it is the significance of the 'automount' setting that I don't understand here.

[jcox]

Sacco,

This is a doc bug due to a feature that required a bit more coordination
between developers than we've had time for in the past few releases.

A JIRA bug was filed and then immediately fixed by a subsequent checkin.
See:  http://issues.alfresco.com/browse/WCM-709

Thanks for pointing this out.

- Jon

PS:
The relevant portion of the config file now looks like this:

# Virtualization server CIFS file system mount point
#    
#     The virtualization server can expose the remote
#     Alfresco AVM repository as a CIFS file system.
#     The properties below specify where (and whether)
#     this automatic mount takes place on Windows
#     and on UNIX-based systems (e.g.: Linux, Mac).
#
#     Exposing a file system interface makes integration
#     simple between the Alfresco repository and normal tools
#     such as the Windows File Explorer, UNIX-based shells,
#     link checkers, and so on.  It also allows JSPs that
#     invoke getRealPath() to work properly.
#    
#     On Windows, the ".unix" properties are ignored.
#     On Linux,   the ".win"  properties are ignored.
#    
alfresco.virtserver.cifs.avm.versiontree.win=v
alfresco.virtserver.cifs.avm.versiontree.unix=/media/alfresco/cifs/v
     
# NOTE:
#       The CIFS automount feature has not been implemented.
#       Therefore, the configuration options below are only
#       placeholders, and currently have no effect. 
#                  
#       Once CIFS automount is implemented, you'll be able to
#       enable/disable it here (by default it will be enabled).
#
alfresco.virtserver.cifs.avm.versiontree.win.automount=true
alfresco.virtserver.cifs.avm.versiontree.unix.automount=true

[sacco]

Thanks for the quick reply, Jon;  I suspected something of the sort, but wanted to be sure that I didn't have, e.g, a misconfig elsewhere that was blocking something.

I strikes me that it might be useful for the purposes of integration with such features (and to facilitate integration with, for example, another server which mounts an Alfresco filesystem) to have a trivial semaphore of some kind to allow an external script to check if Alfresco is up and ready.

The simplest possibility, I think, would be a port which is open (i.e. listened to) when Alfresco is ready, and otherwise not; what I had in mind was something simple and trivial that wouldn't take any significant effort either to implement or to use: it wouldn't need to actually respond in any way, unless you later wanted to add some kind of status monitoring (SNMP?).

[jcox]

Something like the mechanism you're describing
is already in place;  the tricky part is just making
things work cross-platform in a reliable way. 

This amounts to going through all the possible
CIFS server-side configs on the server side,
looking at the clients available on the client
side, and "doing the right thing" for most folks
most of the time by default, and deal with the
possibility of port conflicts and differences in
security policies from box to box; the virt
server may not be on the same box, and
in the near future, you'll be able to have more
than one virt server….

None of this is really rocket science, but there's
a fair amount of fit-and-finish work to do in order
to pull this off smoothly.  Hopefully, we'll get to it
soon.  I really love CIFS and I'd like to make it
as easy as possible for folks to use.


    Thanks again for your comments,
    -Jon

[sacco]

Hi Jon

Thanks again for your comments,

You're welcome.

I had in mind perhaps something even more general:
suppose that I wish to use apache to serve a site managed
in Alfresco and made available to apache through CIFS,
NFS, or whatever.
(ok, I should probably be using  deployment in this particular
case, but it's just an example.)

It would be useful if there were some simple and generic way
to test when the Alfresco server is up and ready to deliver
files.  One could of course just try to mount and read files,
but it would be better if there were some explicit way for the
server to say "I'm ready now", rather than each implementor
hacking together a script to check that initialisation has reached
the point where X can be seen.

For example, I have been having the problem that my Virtualisation
server is giving up rather than retying until the main server comes up:

http://forums.alfresco.com/viewtopic.php?t=7893

For the time being I have worked around this simple by inserting
something like the following into the start-up script to make it wait
until the port is open:

while  ! 4</dev/tcp/${Alf_Server:=localhost}/${Alf_JMX_port:=50500} true \
   2>/dev/null  4<&- ;
  do  4<&-  sleep 1s ; done  4<&-  2>/dev/null 
‍‍‍‍‍

It doesn't necessarily need to be any more complicated than this.
However, it would obviously be better if there were an 'official' semaphore
to check which signified that initialisation is complete, rather than my
ad hoc hack. 
(Version 2 of this might allow some information about the state of the
Alfresco server to be read.)

[jcox]

The issue of the virtualization server giving up has been resolved
in Alfresco 2.1 ENTERPRISE. 

For details see:
http://issues.alfresco.com/browse/WCM-750