Menu
▾
▴
naviserver-devel
|
From: Vlad S. <vl...@cr...> - 2006-09-07 04:40:17
|
I would like to put some explanation about my last commit because it looks like a lot of stuff changed but actually not. The purpose was to run with smallest possible nsd.tcl with reasonable defaults. The rest is tuning and just to run development or test server i do not need several kilobytes config file. So having that said several places needed to be corrected or added some defaults, with existing config files nobody will see the difference. Most noticeable changes are: - if nscp loaded without settings, it will listen on 127.0.0.1 port 2080 and will accept connections with empty username and password. I think this is reasonable for development server. - if no home parameter specified, nsd will try to figure it using binary executable, for now it parses Unix pathname only - if no servers defined, it will run server "default", i.e. it silently creates server "default" in config section "ns/servers" So, minimal config now contains only section for loading modules for server "default". I think, every module should able to be loaded without any server, i.e. with server parameter = NULL in Ns_ModuleInit. Currently nsdb module does not support this and other modules as well, so i will research this more. Once done, it will be possible to load nsd with global modules as standalone server without over-complicated virtual server mess. Simple config, easier to use and debug. -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-09-07 18:25:26
|
On 9/7/06, Vlad Seryakov <vl...@cr...> wrote: > > - if nscp loaded without settings, it will listen on 127.0.0.1 port > 2080 and will accept connections with empty username and password. I > think this is reasonable for development server. This is insecure as a default and we have to change it. The nscp module should *not* be loaded by default, and we shouldn't be hard coding default user names and passwords. We espescially shouldn't be doing both at the same time. It's no trouble at all to remove a single '#' to enable a module. This also applies to the nsstats functionality -- off by default please. |
|
From: Stephen D. <sd...@gm...> - 2006-09-07 18:59:01
|
On 9/7/06, Vlad Seryakov <vl...@cr...> wrote: > > - if no servers defined, it will run server "default", i.e. it silently > creates server "default" in config section "ns/servers" Er, no. No crazy magic to auto-create config behind your back. Virtual servers just aren't complicated. They're a feature, and they're embedded deeply into the core code (all the references to char *server in the C API) so it's not going any where quickly. I agree with your over all goal, which is to have a minimal config file able to boot and run a functional server, right? This is definitely a good idea. The current sample-config.tcl doesn't handle this case well, and it shouldn't -- it's supposed to be a complete reference to all config values. So, we need some other way to handle basic servers. Magic config construction just isn't the way to do it though. How about we move nsd-min.tcl you just added to contrib (dumping ground, grrr...) into the top level, and call it simple-config.tcl? We'll have two config files ship by default: sample-config.tcl -- Exhaustive list of all config variables simple-config.tcl -- Basic config needed to run a single virtual server. They will be identical in the sense that the resulting running server will have the same properties, because the sample-config.tcl will be illustrating *optional* config values, and possibly they''' all be commented out. We can rename 'server1' to 'default' if you like. |
|
From: Vlad S. <vl...@cr...> - 2006-09-07 19:11:30
|
Auto magic i do not like myself but it seems too restrictive to have some dummy server definition to start server if there will be only one server anyway. Virtual servers are good feature for advanced use, we used them before when had multiple servers. But to start one simple web server, i think it does not need to be that complicated, enabling module you want and have it running is good way to immediately see it working. I agree, making it open or less secure just to be able simply run is bad, but if security is not involved and no changes in the core for running default/complex configs, maybe it is not that bad once it documented and logged? Stephen Deasey wrote: > On 9/7/06, Vlad Seryakov <vl...@cr...> wrote: >> - if no servers defined, it will run server "default", i.e. it silently >> creates server "default" in config section "ns/servers" > > > Er, no. > > No crazy magic to auto-create config behind your back. Virtual > servers just aren't complicated. They're a feature, and they're > embedded deeply into the core code (all the references to char *server > in the C API) so it's not going any where quickly. > > I agree with your over all goal, which is to have a minimal config > file able to boot and run a functional server, right? This is > definitely a good idea. > > The current sample-config.tcl doesn't handle this case well, and it > shouldn't -- it's supposed to be a complete reference to all config > values. > > > So, we need some other way to handle basic servers. Magic config > construction just isn't the way to do it though. How about we move > nsd-min.tcl you just added to contrib (dumping ground, grrr...) into > the top level, and call it simple-config.tcl? > > We'll have two config files ship by default: > > sample-config.tcl -- Exhaustive list of all config variables > simple-config.tcl -- Basic config needed to run a single virtual server. > > They will be identical in the sense that the resulting running server > will have the same properties, because the sample-config.tcl will be > illustrating *optional* config values, and possibly they''' all be > commented out. > > We can rename 'server1' to 'default' if you like. > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-09-07 19:29:59
|
On 9/7/06, Vlad Seryakov <vl...@cr...> wrote: > Auto magic i do not like myself but it seems too restrictive to have > some dummy server definition to start server if there will be only one > server anyway. Virtual servers are good feature for advanced use, we > used them before when had multiple servers. It isn't a dummy server, it's needed. The current example-config.tcl is wrong in a number of respects, for example this comment: # # Server-level configuration # # There is only one server in naviserver, but this is helpful when multiple # servers share the same configuration file. This file assumes that only # one server is in use so it is set at the top in the "server" Tcl variable. # Other host-specific values are set up above as Tcl variables, too. # There isn't only one server! All Tcl commands and procs *have* to run in the context of a virtual server, even if there's only one. Yes, you can have global modules. But not if they register Tcl commands! Which virtual server context do they run with? I guess you could write a module such that when it's loaded globally, it roots around for all virtual servers and adds it's Tcl commands to each. But they don't do that... The idea of creating a default virtual server magically hides this important distinction, which makes it harder over all for people to understand what's going on. > But to start one simple web server, i think it does not need to be that > complicated, enabling module you want and have it running is good way to > immediately see it working. I agree, making it open or less secure just > to be able simply run is bad, but if security is not involved and no > changes in the core for running default/complex configs, maybe it is not > that bad once it documented and logged? Unfortunately you can't tell when security is involved or important, so defaults matter and must be conservative. Luckily, it's trivial to enable to enable modules. I think that a simple-config.tcl will improve the situation 100%. Without all the esoteric config values, which should default to something sane anyway, the config file should fit on a couple of screens or so, singe virtual server included. > Stephen Deasey wrote: > > On 9/7/06, Vlad Seryakov <vl...@cr...> wrote: > >> - if no servers defined, it will run server "default", i.e. it silently > >> creates server "default" in config section "ns/servers" > > > > > > Er, no. > > > > No crazy magic to auto-create config behind your back. Virtual > > servers just aren't complicated. They're a feature, and they're > > embedded deeply into the core code (all the references to char *server > > in the C API) so it's not going any where quickly. > > > > I agree with your over all goal, which is to have a minimal config > > file able to boot and run a functional server, right? This is > > definitely a good idea. > > > > The current sample-config.tcl doesn't handle this case well, and it > > shouldn't -- it's supposed to be a complete reference to all config > > values. > > > > > > So, we need some other way to handle basic servers. Magic config > > construction just isn't the way to do it though. How about we move > > nsd-min.tcl you just added to contrib (dumping ground, grrr...) into > > the top level, and call it simple-config.tcl? > > > > We'll have two config files ship by default: > > > > sample-config.tcl -- Exhaustive list of all config variables > > simple-config.tcl -- Basic config needed to run a single virtual server. > > > > They will be identical in the sense that the resulting running server > > will have the same properties, because the sample-config.tcl will be > > illustrating *optional* config values, and possibly they''' all be > > commented out. > > > > We can rename 'server1' to 'default' if you like. > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > naviserver-devel mailing list > > nav...@li... > > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > > -- > Vlad Seryakov > 571 262-8608 office > vl...@cr... > http://www.crystalballinc.com/vlad/ > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
|
From: Vlad S. <vl...@cr...> - 2006-09-07 19:38:47
|
> > It isn't a dummy server, it's needed. The current example-config.tcl > is wrong in a number of respects, for example this comment: > > # > # Server-level configuration > # > # There is only one server in naviserver, but this is helpful when multiple > # servers share the same configuration file. This file assumes that only > # one server is in use so it is set at the top in the "server" Tcl variable. > # Other host-specific values are set up above as Tcl variables, too. > # > > There isn't only one server! All Tcl commands and procs *have* to run > in the context of a virtual server, even if there's only one. I can put it in other words: there is always virtual server in NaviServer, if not defined in config file, internal server "default" is used instead. It is impossible to run nsd without virtual server, so instead of exiting with error internal server is used. I am not insisting on doing it the way i did but it seemed to me very logical and not breaking overall NS architecture or model. But of course, suggestions are welcome, this is development version under discussion. > Yes, you can have global modules. But not if they register Tcl > commands! Which virtual server context do they run with? > > I guess you could write a module such that when it's loaded globally, > it roots around for all virtual servers and adds it's Tcl commands to > each. But they don't do that... > > The idea of creating a default virtual server magically hides this > important distinction, which makes it harder over all for people to > understand what's going on. This part actuall out of sync with overall NS model and logic, the only module that does it is nssock and it was made so for enabling host based virtual server support. I think this is ill and needs to be removed or re-build, if we always have virtual server, its nssock can do host mapping, no need to load it globally and global modules should be eliminated. -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2006-09-07 19:50:17
|
On 9/7/06, Vlad Seryakov <vl...@cr...> wrote: > > > > It isn't a dummy server, it's needed. The current example-config.tcl > > is wrong in a number of respects, for example this comment: > > > > # > > # Server-level configuration > > # > > # There is only one server in naviserver, but this is helpful when multiple > > # servers share the same configuration file. This file assumes that only > > # one server is in use so it is set at the top in the "server" Tcl variable. > > # Other host-specific values are set up above as Tcl variables, too. > > # > > > > There isn't only one server! All Tcl commands and procs *have* to run > > in the context of a virtual server, even if there's only one. > > I can put it in other words: there is always virtual server in > NaviServer, if not defined in config file, internal server "default" is > used instead. It is impossible to run nsd without virtual server, so > instead of exiting with error internal server is used. > > I am not insisting on doing it the way i did but it seemed to me very > logical and not breaking overall NS architecture or model. > > But of course, suggestions are welcome, this is development version > under discussion. The stuff about virtual servers in the config file just isn't hard. And the problem with hiding them is that it really gives people the wrong mental-model about how things work. > > Yes, you can have global modules. But not if they register Tcl > > commands! Which virtual server context do they run with? > > > > I guess you could write a module such that when it's loaded globally, > > it roots around for all virtual servers and adds it's Tcl commands to > > each. But they don't do that... > > > > The idea of creating a default virtual server magically hides this > > important distinction, which makes it harder over all for people to > > understand what's going on. > > This part actuall out of sync with overall NS model and logic, the only > module that does it is nssock and it was made so for enabling host based > virtual server support. I think this is ill and needs to be removed or > re-build, if we always have virtual server, its nssock can do host > mapping, no need to load it globally and global modules should be > eliminated. Hmm, not sure. The nsdb module is also a global module. But it's kinda weird... |
|
From: Vlad S. <vl...@cr...> - 2006-09-08 00:42:32
|
> > Hmm, not sure. The nsdb module is also a global module. But it's > kinda weird... I checked, nsdb cannot be loaded globally, expects not-NULL server, so we have only nssock that can be loaded globally and actually for nssock itself it does not matter because driver/c uses SetServer anyway to find appropriate server. So i think we may decide to get rid of global modules all together. -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Vlad S. <vl...@cr...> - 2006-09-08 01:08:44
|
Vlad Seryakov wrote:
>> Hmm, not sure. The nsdb module is also a global module. But it's
>> kinda weird...
>
> I checked, nsdb cannot be loaded globally, expects not-NULL server, so
> we have only nssock that can be loaded globally and actually for nssock
> itself it does not matter because driver/c uses SetServer anyway to find
> appropriate server.
>
> So i think we may decide to get rid of global modules all together.
>
The only change will be in driver.c:
instead of:
if (sockPtr->servPtr == NULL) {
it will be:
if (hosts.numEntires > 0) {
the rest is the same:
if (host) {
hPtr = Tcl_FindHashEntry(&hosts, host);
if (hPtr != NULL) {
mapPtr = Tcl_GetHashValue(hPtr);
}
}
if (!mapPtr) {
mapPtr = defMapPtr;
}
if (mapPtr) {
sockPtr->servPtr = mapPtr->servPtr;
sockPtr->location = mapPtr->location;
}
if (sockPtr->servPtr == NULL) {
status = 0;
}
}
And those lines from Ns_DriverInit should be removed:
if (server == NULL) {
if (defserver == NULL) {
Ns_Fatal("%s: virtual servers configured,"
" but %s has no defaultserver defined", module, path);
}
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Mike <nee...@gm...> - 2006-09-08 02:36:11
|
On 9/7/06, Vlad Seryakov <vl...@cr...> wrote: > I am not insisting on doing it the way i did but it seemed to me very > logical and not breaking overall NS architecture or model. > > But of course, suggestions are welcome, this is development version > under discussion. My 2c: I like Stephen's suggestion of a barebones config file. If I run "the default" and I want to figure out what some parameter is set to, I want to open the config file and read it. I do not want to go and hunt down the docs to try to figure out the config param that is missing that assumes some default that's documented in yet another place. Bloat in the example config is bad - magic is worse... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X