Re: [cobalt-users] raq2- Front Page enable.site

["support@xxxxxxxxxxx" <support@xxxxxxxxxxx>]

Will,

Oh, man, I forgot to answer this post and I'd hate for you not to
implement subwebs in SOME form just cause we were lazy... YES, I for one
desperately need cobalt to support FP subwebs in whatever fashion they
can. Maybe one in 10 customers asks me "how do I create subwebs?"

I do not personally use FP so, hazarding a guess, I usually tell my
hosting customers to create a new user web instead. It gets kind of
painful wasting support hours on it.


Ray Davis wrote:
> 
> Will - thanks for the reply!
> 
> Ah well - *I* personally would not find it useful since I don't even
> use FP.  :)  But as an ISP who has a customer complaining that he
> can't split up his web into subwebs, yes I would find it useful.
> 
> Whether he actually needs them or not is pretty much irrelevant.
> A customer doesn't want to be told he doesn't need to do what he's
> doing.  And if he switches to another provider who can offer real
> FP compatibility then I've lost a customer which is enough income
> to buy another RaQ every month.  :)
> 
> In fact, it would be great if your implementation would also allow
> these virtual user perms in the root subwebs just to be 100% FP
> Extension Compatible.  Perhaps there could be a toggle between
> passwd file auth and fp user auth somehow?
> 
> As much as I hate it, Microsloth offers something and the rest of the
> world has to play the tune.  :(
> 
> *sigh*
> Ray
> 
> > Hi Ray,
> >
> > Thanks for the great post.
> >
> > Subwebs can be used to split up a very large root or user web for
> > publishing and searching which could avoid FP timeouts for 10,000+ page
> > webs.  Would you (& the rest of cobalt-users) find subwebs that share
> > access permissions with their root or user web useful?
> >
> > It is not possible to implement this by hand just using fpsrvadm.exe as
> > Cobalt RaQs implement supplemental access management and file
> > permissions control.  However, scripts could be developed to manage this
> > restricted subweb support.
> >
> >
> >       -- Will
> >
> > Ray Davis wrote:
> > >
> > > Hi Will,
> > >
> > > > There is no subweb support as subwebs, on non-Cobalt unix servers, are
> > > > delegated to virtual users, which doesn't fit the site admin/regular
> > > > user security model.  Cobalt FP security hinges on every user having a
> > > > real account on the server.
> > >
> > > As far as I can glean from the SERK (as someone who never touched FP),
> > > subwebs can be delegated to virtual users but don't have to be.  They
> > > can inherit the same perms as the root web and simply be used as an
> > > organizational tool.  A subweb can have different defaults and can
> > > be rebuilt/uploaded separately from the root web.  They don't have to
> > > be used as a way to allow different people permissions to access
> > > different parts of a single web site.
> > >
> > > So is it theoretically possible (via fpsrvadm.exe or by hand) to
> > > create a subweb where the user perms are the same as the root web?
> > >
> > > Here is a blurb from /serk/adfpsr_2.htm (note my *>s) ...
> > >
> > >     Create Command
> > >
> > >     Creates a FrontPage-extended subweb at the specified directory
> > >     in an existing FrontPage-extended web.
> > >
> > >     Syntax
> > >
> > >     fpsrvadm.exe -o create -p nnnn -m HostName -w WebName [-u UserName]
> > >         [-pw password] [ -xu UNIXUserName] [ -xg UNIXGroupName] [ -n yes]
> > >
> > >     Notes
> > >
> > >     For WebName, specify the path from the root directory of the
> > >     content area to the subweb that you are creating. The -pw
> > >     password argument is not needed on IIS servers.
> > >
> > >  *> If UserName and password are blank, security settings for new
> > >  *> subwebs are inherited from the root web. If these arguments are
> > >     not blank, the new subweb will have unique permissions with an
> > >     initial administrator account based on UserName and password.
> > >
> > > Thanks,
> > > Ray
> > >
> > > _______________________________________________
> > > cobalt-users mailing list
> > > cobalt-users@xxxxxxxxxxxxxxx
> > > http://list.cobalt.com/mailman/listinfo/cobalt-users
> >
> > _______________________________________________
> > cobalt-users mailing list
> > cobalt-users@xxxxxxxxxxxxxxx
> > http://list.cobalt.com/mailman/listinfo/cobalt-users
> 
> _______________________________________________
> cobalt-users mailing list
> cobalt-users@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-users

-- 
Clayton McGow		        
support@xxxxxxxxxxx		
http://www.atoznet.com