Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use?

This WebDNA talk-list message is from

2011


It keeps the original formatting.
numero = 107219
interpreted = N
texte = > Hi Ken! checking now with a developer. So far, WebDNA 7.0 > can run with any linux version, including Ubuntu 11. It > should work with Debian 6. Just give us few daytime > hours :-) > > WebDNA 7.0 will run with any linux version, we just need > to know if it is a 32bit or 64bit, if it is a glibcv2 > (Fedora, Red Hat, CentOS..) or glibcv3 (Debian, > Ubutuntu...) and finally, Ubuntu 10 or 11 will request a > specific libmysql. Hi Chris, Thanks for this info. Of course I'll give you more daytime hours to help me get WebDNA working again! :) I wonder if Debian 5 and 6 request different libmysql files similar to the way Ubuntu does? I also wonder if it might be better for WSC if you were to have your developer code WebDNA so that it looks for its required dependencies inside the WebDNA folder from now on? Then let us create symlinks to the required files in the WebDNA folder. Wouldn't this eliminate the possibility of WebDNA failing to find a dependency and then failing to start if the dependency is not in the expected location, or if it is but has a different name? In Debian 5 we already need to create a symlink to libssl.so.6 because the file WebDNA expects to find is actually named libssl.so. But we are putting that symlink in the /usr/lib/ folder rather than in the WebDNA folder like this: # ln -s /usr/lib/libssl.so /usr/lib/libssl.so.6 All I'm suggesting here is that we create a symlink to the same libssl.so file, then put it inside the WebDNA folder instead of in /usr/lib/. And do the same thing for all the other dependency files. Then no matter what build we're using, WebDNA will always look for required files inside the WebDNA folder. And when WebDNA fails to start we can confirm that it's dependencies exist (or do not exist) simply by looking inside the WebDNA folder and checking to see that all the required symlinks exist -- and are connected to the correct original files. Is there any reason why this would not work? Another good change might be for the WebDNA executable to have an obvious naming convention that tells us which build we are actually using. For example: WebDNAv0701b32g2.fcgi = version 7.1 32bit glibcv2 WebDNAv0724b32g3.fcgi = version 7.24 32bit glibcv3 WebDNAv0703b64g2.fcgi = version 7.3 64bit glibcv2 WebDNAv0748b64g3.fcgi = version 7.48 64bit glibcv3 If this were possible I might not have experienced this problem in the first place, assuming I'm using the wrong executable, because I would have known which one to use from the beginning. If you decide to adopt such a naming convention we can just use a symlink from one of the above executables to WebDNA.fcgi so that our apache / lighttpd / nginx configuration does not have to change when we switch from one WebDNA executable to another. Just some thoughts for possible consideration, that's all. :) Sincerely, Kenneth Grome P.S. I have a WebDNA.fcgi that works on my Ubuntu 10.10 desktop development computer, but I'm going to need one that works on Ubuntu 11 when I upgrade pretty soon too, so maybe you can send me the ones for Debian 6 and Ubuntu 11 when they are ready. Thanks! Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (Kenneth Grome 2011)
  2. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (Kenneth Grome 2011)
  3. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (christophe.billiottet@webdna.us 2011)
  4. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (Kenneth Grome 2011)
  5. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (christophe.billiottet@webdna.us 2011)
  6. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (Kenneth Grome 2011)
  7. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (christophe.billiottet@webdna.us 2011)
  8. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (Kenneth Grome 2011)
  9. Re: [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (christophe.billiottet@webdna.us 2011)
  10. [WebDNA] How do we tell what's misconfigured? Or which WebDNA 7 version to use? (Kenneth Grome 2011)
> Hi Ken! checking now with a developer. So far, WebDNA 7.0 > can run with any linux version, including Ubuntu 11. It > should work with Debian 6. Just give us few daytime > hours :-) > > WebDNA 7.0 will run with any linux version, we just need > to know if it is a 32bit or 64bit, if it is a glibcv2 > (Fedora, Red Hat, CentOS..) or glibcv3 (Debian, > Ubutuntu...) and finally, Ubuntu 10 or 11 will request a > specific libmysql. Hi Chris, Thanks for this info. Of course I'll give you more daytime hours to help me get WebDNA working again! :) I wonder if Debian 5 and 6 request different libmysql files similar to the way Ubuntu does? I also wonder if it might be better for WSC if you were to have your developer code WebDNA so that it looks for its required dependencies inside the WebDNA folder from now on? Then let us create symlinks to the required files in the WebDNA folder. Wouldn't this eliminate the possibility of WebDNA failing to find a dependency and then failing to start if the dependency is not in the expected location, or if it is but has a different name? In Debian 5 we already need to create a symlink to libssl.so.6 because the file WebDNA expects to find is actually named libssl.so. But we are putting that symlink in the /usr/lib/ folder rather than in the WebDNA folder like this: # ln -s /usr/lib/libssl.so /usr/lib/libssl.so.6 All I'm suggesting here is that we create a symlink to the same libssl.so file, then put it inside the WebDNA folder instead of in /usr/lib/. And do the same thing for all the other dependency files. Then no matter what build we're using, WebDNA will always look for required files inside the WebDNA folder. And when WebDNA fails to start we can confirm that it's dependencies exist (or do not exist) simply by looking inside the WebDNA folder and checking to see that all the required symlinks exist -- and are connected to the correct original files. Is there any reason why this would not work? Another good change might be for the WebDNA executable to have an obvious naming convention that tells us which build we are actually using. For example: WebDNAv0701b32g2.fcgi = version 7.1 32bit glibcv2 WebDNAv0724b32g3.fcgi = version 7.24 32bit glibcv3 WebDNAv0703b64g2.fcgi = version 7.3 64bit glibcv2 WebDNAv0748b64g3.fcgi = version 7.48 64bit glibcv3 If this were possible I might not have experienced this problem in the first place, assuming I'm using the wrong executable, because I would have known which one to use from the beginning. If you decide to adopt such a naming convention we can just use a symlink from one of the above executables to WebDNA.fcgi so that our apache / lighttpd / nginx configuration does not have to change when we switch from one WebDNA executable to another. Just some thoughts for possible consideration, that's all. :) Sincerely, Kenneth Grome P.S. I have a WebDNA.fcgi that works on my Ubuntu 10.10 desktop development computer, but I'm going to need one that works on Ubuntu 11 when I upgrade pretty soon too, so maybe you can send me the ones for Debian 6 and Ubuntu 11 when they are ready. Thanks! Kenneth Grome

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Keyword search (2004) Not Authorised Adding Items (1998) Clean Code: Rules for inserting keyboard returns? (1997) I give up!! (1997) Hard Questions ? (1997) using WebCat for Associate Programs? (1998) [Sum] function? (1997) Running _every_ page through WebCat ? (1997) ThisURL (2000) Expected Behavior? (1999) Does anyone have any Whois lookup code in WebCat? (2007) Country & Ship-to address & other fields ? (1997) Help! WebCat2 bug (1997) Scratch & Win (1999) [WebDNA] An alternative to hosting... (2009) The Form authentication trick (2000) Large databases in WebCat (1997) WebCatalog2 Feature Feedback (1996) Mass Mail (2000) showif and cart (1997)