You can subscribe to this list here.
2005 |
Jan
|
Feb
(53) |
Mar
(62) |
Apr
(88) |
May
(55) |
Jun
(204) |
Jul
(52) |
Aug
|
Sep
(1) |
Oct
(94) |
Nov
(15) |
Dec
(68) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(130) |
Feb
(105) |
Mar
(34) |
Apr
(61) |
May
(41) |
Jun
(92) |
Jul
(176) |
Aug
(102) |
Sep
(247) |
Oct
(69) |
Nov
(32) |
Dec
(140) |
2007 |
Jan
(58) |
Feb
(51) |
Mar
(11) |
Apr
(20) |
May
(34) |
Jun
(37) |
Jul
(18) |
Aug
(60) |
Sep
(41) |
Oct
(105) |
Nov
(19) |
Dec
(14) |
2008 |
Jan
(3) |
Feb
|
Mar
(7) |
Apr
(5) |
May
(123) |
Jun
(5) |
Jul
(1) |
Aug
(29) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(3) |
2009 |
Jan
|
Feb
(36) |
Mar
(29) |
Apr
|
May
|
Jun
(7) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(13) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(92) |
Nov
(28) |
Dec
(16) |
2013 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
(4) |
May
(4) |
Jun
(6) |
Jul
(14) |
Aug
(12) |
Sep
(4) |
Oct
(13) |
Nov
(1) |
Dec
(6) |
2014 |
Jan
(23) |
Feb
(19) |
Mar
(10) |
Apr
(14) |
May
(11) |
Jun
(6) |
Jul
(11) |
Aug
(15) |
Sep
(41) |
Oct
(95) |
Nov
(23) |
Dec
(11) |
2015 |
Jan
(3) |
Feb
(9) |
Mar
(19) |
Apr
(3) |
May
(1) |
Jun
(3) |
Jul
(11) |
Aug
(1) |
Sep
(15) |
Oct
(5) |
Nov
(2) |
Dec
|
2016 |
Jan
(7) |
Feb
(11) |
Mar
(8) |
Apr
(1) |
May
(3) |
Jun
(17) |
Jul
(12) |
Aug
(3) |
Sep
(5) |
Oct
(19) |
Nov
(12) |
Dec
(6) |
2017 |
Jan
(30) |
Feb
(23) |
Mar
(12) |
Apr
(32) |
May
(27) |
Jun
(7) |
Jul
(13) |
Aug
(16) |
Sep
(6) |
Oct
(11) |
Nov
|
Dec
(12) |
2018 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(7) |
May
(23) |
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(6) |
Nov
(10) |
Dec
(3) |
2019 |
Jan
(26) |
Feb
(15) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(14) |
Jul
(10) |
Aug
(10) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(10) |
2020 |
Jan
(10) |
Feb
(14) |
Mar
(29) |
Apr
(11) |
May
(25) |
Jun
(21) |
Jul
(23) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(8) |
Dec
(12) |
2021 |
Jan
(29) |
Feb
(9) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(4) |
Nov
(12) |
Dec
(13) |
2022 |
Jan
(4) |
Feb
|
Mar
(4) |
Apr
(12) |
May
(15) |
Jun
(7) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(8) |
Dec
|
2023 |
Jan
(15) |
Feb
|
Mar
(23) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(22) |
Sep
(19) |
Oct
(2) |
Nov
(20) |
Dec
|
2024 |
Jan
(1) |
Feb
|
Mar
(16) |
Apr
(15) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(18) |
Dec
(6) |
2025 |
Jan
(12) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(11) |
Jun
(5) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Gustaf N. <ne...@wu...> - 2020-05-11 08:25:50
|
Dear Fox, There is absolutely no reason that the Tcl-builtin function zlib returns different results in tclsh and naviserver. I could not reproduce different results in these two environments, also when modifying the compression level (see comments below). I slightly modified your script my making sure that the resulting file is binary and contains no extra newline at the end. While correcting this, i noticed that the size of the file differed in the range as you reported when writing the file binary or not (as in your case). So, my suspicion is that you compared the result of binary result writing in tclsh with non-binary result writing in NaviServer. Can you report the different results with the modified script? -g ================================== set inFile "/tmp/myImage.png" set outFile "/tmp/myImage.png.ixz" set myFile [open $inFile RDONLY] fconfigure $myFile -translation binary set content [read $myFile] close $myFile set binData [encoding convertto utf-8 $content] set hexData [binary encode hex [encoding convertto utf-8 $content]] # level 0 => 2.56 MB # level 6 => 1.13 MB # level not specified 1.13 MB # level 9 => 1.11 MB set fp [open $outFile w] fconfigure $fp -translation binary puts -nonewline $fp [zlib compress $hexData] close $fp puts stderr [subst { /tmp/myImage.png: [clock format [file mtime /tmp/myImage.png]] [file size /tmp/myImage.png] /tmp/myImage.png.ixz [clock format [file mtime /tmp/myImage.png.ixz]] [file size /tmp/myImage.png.ixz] }] On 10.05.20 15:59, D.Fox wrote: > Hi, I am trying to compress a image (.png) using hexadecimal and ZLIB. > When running the below code within naviserver the created file is > larger then if I run standalone shell. > > The sample code is as follows: > ######### > set file "/bench/myImage.png" > set filePath "/bench/" > > set myFile [open $file RDONLY] > fconfigure $ myFile -translation binary > set content [read $myFile] > set binData [encoding convertto utf-8 $content] > set hexData [binary encode hex [encoding convertto utf-8 $content]] > close $myFile > > set fp [open "$filePath/myCompressedHexBlobFile.ixz" w] > puts $fp [zlib compress $hexData] > close $fp > ######### > Outputs: > 846K - myImage.png > 1.7M - myCompressedHexBlobFile.ixz - Executed within Naviserver > 1.1M - myCompressedHexBlobFile.ixz - Executed from shell with TCLSH > ######### > Is Navi using a different zlib compression level, why is this happening? > If I set the compression level to nine, the created file is still at > 1.7mb. This is kind of a game changer, even if I source the > compression script the file size is still larger then if I run it via > terminal. > > Thanks > Fox > > > > > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: D.Fox <un...@cr...> - 2020-05-10 14:24:25
|
Hi, I am trying to compress a image (.png) using hexadecimal and ZLIB. When running the below code within naviserver the created file is larger then if I run standalone shell. The sample code is as follows: ######### set file "/bench/myImage.png" set filePath "/bench/" set myFile [open $file RDONLY] fconfigure $ myFile -translation binary set content [read $ myFile ] set binData [encoding convertto utf-8 $content] set hexData [binary encode hex [encoding convertto utf-8 $content]] close $ myFile set fp [open "$filePath/myCompressedHexBlobFile.ixz" w] puts $fp [zlib compress $hexData] close $fp ######### Outputs: 846K - myImage.png 1.7M - myCompressedHexBlobFile.ixz - Executed within Naviserver 1.1M - myCompressedHexBlobFile.ixz - Executed from shell with TCLSH ######### Is Navi using a different zlib compression level, why is this happening? If I set the compression level to nine, the created file is still at 1.7mb. This is kind of a game changer, even if I source the compression script the file size is still larger then if I run it via terminal. Thanks Fox |
From: THORPE M. <ta...@me...> - 2020-04-17 16:03:17
|
Hi, I ran the configure file per your instructions. Results were the same this is part of the result when I ran the configuration file: checking for compress2 in -lz... yes checking for OpenSSL libraries... Trying to use directory /opt/include and -L/opt/lib checking openssl/evp.h usability... no checking openssl/evp.h presence... no checking for openssl/evp.h... no checking for OPENSSL_init_ssl in -lssl... no checking for SSL_library_init in -lssl... no checking for PEM_read_bio_DHparams in -lcrypto... no configure: error: OpenSSL support requested but not available port list openssl returned this port list openssl openssl @1.1.1f devel/openssl I changed —with-openssl=/opt to —with-openssl=/opt/include I ran the configure again, make clean, and make. No errors. Is that it? Thank you for your help. Thorpe |
From: Gustaf N. <ne...@wu...> - 2020-04-16 23:16:13
|
This are usual troubles with the many incompatible clones/versions of OpenSSL. The error message tells you that the electronic signature stuff is missing in the library. I have on my machine macOS Mojave, where i do not see this. It might be the case that the compilation picks up the OpenSSL clone of macOS. One option is to go to the build directory (usually /usr/local/src/naviserver) and run there (assuming you are using a not locally modified install-ns.sh) the following commands: configure --enable-threads --with-tcl=/usr/local/ns/lib --prefix=/usr/local/ns --with-openssl=/opt make clean; make What is the output of the following command? port list openssl all the best -gn On 17.04.20 00:32, THORPE MAYES via naviserver-devel wrote: > Hi, > > I am installing NaviServer on a Mac with MacOS Catalina. > > When I run install-ns.sh build I get this at the end of the process: > > config.status: creating include/nsconfig.h > make[1]: Nothing to be done for `all'. > gcc -Os -DNDEBUG -DSYSTEM_MALLOC -Wall -fno-common -pipe -I../include > -I"/usr/local/ns/include" -DHAVE_CONFIG_H -I/opt/local/include > -c -o tclcrypto.o tclcrypto.c > *tclcrypto.c:1331:55: **warning: **passing 'const unsigned char *' to > parameter of type 'unsigned char *' discards qualifiers > [-Wincompatible-pointer-types-discards-qualifiers]* > (const unsigned > char *)signatureString, > * ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* > */opt/local/include/openssl/evp.h:580:19: note: *passing argument to > parameter 'sig' here > unsigned char *sig, size_t siglen); > * ^* > *tclcrypto.c:2672:56: **error: **use of undeclared identifier > 'EVP_CIPH_GCM_MODE'* > } else if ((result = GetCipher(interp, cipherName, > EVP_CIPH_GCM_MODE, "gcm", cipherPtr)) == TCL_OK) { > * ^* > *tclcrypto.c:2783:46: **error: **use of undeclared identifier > 'EVP_CTRL_GCM_SET_IVLEN'* > || (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, > ivLength, NULL) != 1) > * ^* > *tclcrypto.c:2831:42: **error: **use of undeclared identifier > 'EVP_CTRL_GCM_GET_TAG'* > EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, > tagDs.length, tagDs.string); > * ^* > *tclcrypto.c:2862:53: **error: **use of undeclared identifier > 'EVP_CTRL_GCM_SET_IVLEN'* > || (EVP_CIPHER_CTX_ctrl(ctx, > EVP_CTRL_GCM_SET_IVLEN, ivLength, NULL) != 1) > * ^* > *tclcrypto.c:2901:45: **error: **use of undeclared identifier > 'EVP_CTRL_GCM_SET_TAG'* > if(EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, > tagLength, tagString) != 1) { > * ^* > 1 warning and 5 errors generated. > make[1]: *** [tclcrypto.o] Error 1 > make: *** [all] Error 1 > > I do not know where to go from here. I appreciate any advice. |
From: THORPE M. <ta...@me...> - 2020-04-16 22:32:26
|
Hi, I am installing NaviServer on a Mac with MacOS Catalina. When I run install-ns.sh build I get this at the end of the process: config.status: creating include/nsconfig.h make[1]: Nothing to be done for `all'. gcc -Os -DNDEBUG -DSYSTEM_MALLOC -Wall -fno-common -pipe -I../include -I"/usr/local/ns/include" -DHAVE_CONFIG_H -I/opt/local/include -c -o tclcrypto.o tclcrypto.c tclcrypto.c:1331:55: warning: passing 'const unsigned char *' to parameter of type 'unsigned char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] (const unsigned char *)signatureString, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /opt/local/include/openssl/evp.h:580:19: note: passing argument to parameter 'sig' here unsigned char *sig, size_t siglen); ^ tclcrypto.c:2672:56: error: use of undeclared identifier 'EVP_CIPH_GCM_MODE' } else if ((result = GetCipher(interp, cipherName, EVP_CIPH_GCM_MODE, "gcm", cipherPtr)) == TCL_OK) { ^ tclcrypto.c:2783:46: error: use of undeclared identifier 'EVP_CTRL_GCM_SET_IVLEN' || (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, ivLength, NULL) != 1) ^ tclcrypto.c:2831:42: error: use of undeclared identifier 'EVP_CTRL_GCM_GET_TAG' EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, tagDs.length, tagDs.string); ^ tclcrypto.c:2862:53: error: use of undeclared identifier 'EVP_CTRL_GCM_SET_IVLEN' || (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, ivLength, NULL) != 1) ^ tclcrypto.c:2901:45: error: use of undeclared identifier 'EVP_CTRL_GCM_SET_TAG' if(EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, tagLength, tagString) != 1) { ^ 1 warning and 5 errors generated. make[1]: *** [tclcrypto.o] Error 1 make: *** [all] Error 1 I do not know where to go from here. I appreciate any advice. Thorpe |
From: Iuri S. <iu...@iu...> - 2020-04-12 14:54:36
|
Hi Andrew, Habr you tried the other repositories: https://downloads.sourceforge.net/sourceforge/naviserver/naviserver-${version_ns}.tar.gz https://github.com/nm-wu <https://github.com/nm-wu> fi They are all used in the installation scripts written by Gustaf. https://github.com/gustafn/install-ns <https://github.com/gustafn/install-ns> I grabbed those two from there. There are a few more. Happy Easter, I > On Apr 12, 2020, at 01:25, Andrew Piskorski <at...@pi...> wrote: > > On Fri, Apr 10, 2020 at 02:19:50PM -0400, Andrew Piskorski wrote: > >> https://bitbucket.org/naviserver/naviserver/commits/ >> >> The weird thing is, after doing the commands below to update my clone, >> the MOST recent commit I see is still only from 2020-04-05, Gustaf's >> "add debug entries to 404 returns". The three more recent commits on >> the website are apparently NOT in my local repository at all! > > Still had the same problem, so I discarded my local repository and > cloned again from scratch. I'm still not sure what the problem was, > but I notice that this new repository includes my BitBucket username > in the URL, while the old one did not. AFAIK that should not matter, > but perhaps it did somehow. > > $ git remote -v > origin https://api...@bi.../naviserver/naviserver.git (fetch) > origin https://api...@bi.../naviserver/naviserver.git (push) > > -- > Andrew Piskorski <at...@pi...> > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Andrew P. <at...@pi...> - 2020-04-12 04:26:09
|
On Fri, Apr 10, 2020 at 02:19:50PM -0400, Andrew Piskorski wrote: > https://bitbucket.org/naviserver/naviserver/commits/ > > The weird thing is, after doing the commands below to update my clone, > the MOST recent commit I see is still only from 2020-04-05, Gustaf's > "add debug entries to 404 returns". The three more recent commits on > the website are apparently NOT in my local repository at all! Still had the same problem, so I discarded my local repository and cloned again from scratch. I'm still not sure what the problem was, but I notice that this new repository includes my BitBucket username in the URL, while the old one did not. AFAIK that should not matter, but perhaps it did somehow. $ git remote -v origin https://api...@bi.../naviserver/naviserver.git (fetch) origin https://api...@bi.../naviserver/naviserver.git (push) -- Andrew Piskorski <at...@pi...> |
From: Andrew P. <at...@pi...> - 2020-04-10 18:20:07
|
Last week, I cloned the BitBucket naviserver git repository. Now, I see that it has some new commits, so I want to pull them into my local clone: https://bitbucket.org/naviserver/naviserver/commits/ The weird thing is, after doing the commands below to update my clone, the MOST recent commit I see is still only from 2020-04-05, Gustaf's "add debug entries to 404 returns". The three more recent commits on the website are apparently NOT in my local repository at all! Am I doing something wrong with Git, or is this some sort of bug on BitBucket's end? $ git remote -v origin https://bitbucket.org/naviserver/naviserver.git (fetch) origin https://bitbucket.org/naviserver/naviserver.git (push) $ git fetch --all Fetching origin $ git log --full-history -n 2 '--date=format:%Y-%m-%d %T %z %a' commit 56492e5643367c57a2ea76128ea8b1d86e1be999 (HEAD -> master) Author: Gustaf Neumann <ne...@wu...> Date: 2020-04-05 21:20:29 +0200 Sun add debug entries to 404 returns commit d5a4faaf07dc54e12afbac8e40b1c36575c64f62 Author: Gustaf Neumann <ne...@wu...> Date: 2020-04-05 21:19:49 +0200 Sun change version number to 4.99.20a -- Andrew Piskorski <at...@pi...> |
From: David O. <da...@qc...> - 2020-04-07 08:00:14
|
Hi, I don't think we knew about ns_uuid. uuid::uuid is now used in quite a few places in the codebase. We can do an audit and change to a wrapper proc which uses uuid::uuid or ns_uuid depending on whether the proc is being called within NaviServer or not... but I wanted to make sure there was a good reason to introduce the extra complexity. On Mon, 6 Apr 2020 at 18:26, Gustaf Neumann <ne...@wu...> wrote: > Dear David, > > is there any reason not using "ns_uuid"? > > -g > On 06.04.20 17:02, David Osborne wrote: > > Hi, > Hope everyone is well. > > We encountered a situation where uuids generated by tcllib's uuid::uuid > generate can repeat sequences under naviserver which has caused some > issues in our codebase with collisions. > We wondered if you would expect this behaviour? > > Using Debian 9.7 with Naviserver 4.99.19 tarball. > > We have a /usr/local/ns/tcl/test.tcl file: > > proc uuid_test {} { > ns_return 200 text/plain [uuid::uuid generate] > } > package require uuid > ns_register_proc GET /test.tcl uuid_test > > Then we start naviserver with: > sudo /usr/local/ns/bin/nsd -u nsadmin -t /usr/local/ns/conf/nsd-config.tcl > > Each request starts off with unique uuids: > > $ curl http://127.0.0.1:8080/test.tcl > 94648710-5503-4ecb-8853-7acd68fe289c > $ curl http://127.0.0.1:8080/test.tcl > de3a7eee-8b4d-45b9-b80c-71985b2b6346 > $ curl http://127.0.0.1:8080/test.tcl > efec82f4-2e0f-43ff-a951-6abb0a9a61a9 > > Then if we do a ns_eval -sync source of any file: > > $ nc 127.0.0.1 4080 > Welcome to default running at /usr/local/ns/bin/nsd (pid 12248) > NaviServer/4.99.19 for linux built on Apr 6 2020 at 14:27:50 > Tag: tar-4.99.19 > default:nscp 1> ns_eval -sync source /usr/local/ns/tcl/file.tcl > > We are given the same sequence of uuids again: > > $ curl http://127.0.0.1:8080/test.tcl > 94648710-5503-4ecb-8853-7acd68fe289c > $ curl http://127.0.0.1:8080/test.tcl > de3a7eee-8b4d-45b9-b80c-71985b2b6346 > $ curl http://127.0.0.1:8080/test.tcl > efec82f4-2e0f-43ff-a951-6abb0a9a61a9 > > The same issue does *not* happen with your ns_uuid implementation. > > We dug into the implementation details of the tcllib version. I'm not > familiar with the uuid algorithm particularly, but it seems when initially > called, the code generates some random data to use when making the uuid > which it calls machinfo. This is then cached and will not change as long > as the variable exists in memory. The only thing making each subsequent > request different is an incrementing counter (called uid) which is used in > the MD5 hash. > What happens with ns_eval, is that this counter (uid) is reset, the machinfo > stays the same, so the same sequence of uuids begins again. > > https://github.com/tcltk/tcllib/blob/master/modules/uuid/uuid.tcl#L37 > > What's your take on this behaviour? > Thanks, > -- > David > > > _______________________________________________ > naviserver-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > -- *David Osborne | Software Engineer* Qcode Software, Castle House, Fairways Business Park, Inverness, IV2 6AA *Email:* da...@qc... | *Phone:* 01463 896 484 www.qcode.co.uk |
From: Gustaf N. <ne...@wu...> - 2020-04-06 17:26:10
|
Dear David, is there any reason not using "ns_uuid"? -g On 06.04.20 17:02, David Osborne wrote: > Hi, > Hope everyone is well. > > We encountered a situation where uuids generated by tcllib's > uuid::uuid generate can repeat sequences under naviserver which has > caused some issues in our codebase with collisions. > We wondered if you would expect this behaviour? > > Using Debian 9.7 with Naviserver 4.99.19 tarball. > > We have a /usr/local/ns/tcl/test.tcl file: > > proc uuid_test {} { > ns_return 200 text/plain [uuid::uuid generate] > } > package require uuid > ns_register_proc GET /test.tcl uuid_test > > Then we start naviserver with: > sudo /usr/local/ns/bin/nsd -u nsadmin -t /usr/local/ns/conf/nsd-config.tcl > > Each request starts off with unique uuids: > > $ curl http://127.0.0.1:8080/test.tcl > 94648710-5503-4ecb-8853-7acd68fe289c > $ curl http://127.0.0.1:8080/test.tcl > de3a7eee-8b4d-45b9-b80c-71985b2b6346 > $ curl http://127.0.0.1:8080/test.tcl > efec82f4-2e0f-43ff-a951-6abb0a9a61a9 > > Then if we do a ns_eval -sync source of any file: > > $ nc 127.0.0.1 4080 > Welcome to default running at /usr/local/ns/bin/nsd (pid 12248) > NaviServer/4.99.19 for linux built on Apr 6 2020 at 14:27:50 > Tag: tar-4.99.19 > default:nscp 1> ns_eval -sync source /usr/local/ns/tcl/file.tcl > > We are given the same sequence of uuids again: > > $ curl http://127.0.0.1:8080/test.tcl > 94648710-5503-4ecb-8853-7acd68fe289c > $ curl http://127.0.0.1:8080/test.tcl > de3a7eee-8b4d-45b9-b80c-71985b2b6346 > $ curl http://127.0.0.1:8080/test.tcl > efec82f4-2e0f-43ff-a951-6abb0a9a61a9 > > The same issue does *not* happen with your ns_uuid implementation. > > We dug into the implementation details of the tcllib version. I'm not > familiar with the uuid algorithm particularly, but it seems when > initially called, the code generates some random data to use when > making the uuid which it calls machinfo. This is then cached and will > not change as long as the variable exists in memory. The only thing > making each subsequent request different is an incrementing counter > (called uid) which is used in the MD5 hash. > What happens with ns_eval, is that this counter (uid) is reset, the > machinfo stays the same, so the same sequence of uuids begins again. > > https://github.com/tcltk/tcllib/blob/master/modules/uuid/uuid.tcl#L37 > > What's your take on this behaviour? > Thanks, > -- > David > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: David O. <da...@qc...> - 2020-04-06 15:28:10
|
Hi, Hope everyone is well. We encountered a situation where uuids generated by tcllib's uuid::uuid generate can repeat sequences under naviserver which has caused some issues in our codebase with collisions. We wondered if you would expect this behaviour? Using Debian 9.7 with Naviserver 4.99.19 tarball. We have a /usr/local/ns/tcl/test.tcl file: proc uuid_test {} { ns_return 200 text/plain [uuid::uuid generate] } package require uuid ns_register_proc GET /test.tcl uuid_test Then we start naviserver with: sudo /usr/local/ns/bin/nsd -u nsadmin -t /usr/local/ns/conf/nsd-config.tcl Each request starts off with unique uuids: $ curl http://127.0.0.1:8080/test.tcl 94648710-5503-4ecb-8853-7acd68fe289c $ curl http://127.0.0.1:8080/test.tcl de3a7eee-8b4d-45b9-b80c-71985b2b6346 $ curl http://127.0.0.1:8080/test.tcl efec82f4-2e0f-43ff-a951-6abb0a9a61a9 Then if we do a ns_eval -sync source of any file: $ nc 127.0.0.1 4080 Welcome to default running at /usr/local/ns/bin/nsd (pid 12248) NaviServer/4.99.19 for linux built on Apr 6 2020 at 14:27:50 Tag: tar-4.99.19 default:nscp 1> ns_eval -sync source /usr/local/ns/tcl/file.tcl We are given the same sequence of uuids again: $ curl http://127.0.0.1:8080/test.tcl 94648710-5503-4ecb-8853-7acd68fe289c $ curl http://127.0.0.1:8080/test.tcl de3a7eee-8b4d-45b9-b80c-71985b2b6346 $ curl http://127.0.0.1:8080/test.tcl efec82f4-2e0f-43ff-a951-6abb0a9a61a9 The same issue does *not* happen with your ns_uuid implementation. We dug into the implementation details of the tcllib version. I'm not familiar with the uuid algorithm particularly, but it seems when initially called, the code generates some random data to use when making the uuid which it calls machinfo. This is then cached and will not change as long as the variable exists in memory. The only thing making each subsequent request different is an incrementing counter (called uid) which is used in the MD5 hash. What happens with ns_eval, is that this counter (uid) is reset, the machinfo stays the same, so the same sequence of uuids begins again. https://github.com/tcltk/tcllib/blob/master/modules/uuid/uuid.tcl#L37 What's your take on this behaviour? Thanks, -- David |
From: Gustaf N. <ne...@wu...> - 2020-04-05 09:52:09
|
The situation with the aolserver repos in general and on bitbucket in particular is confusing, i also fail to understand, why there is a need for two aolserver repos at bitbucket: https://bitbucket.org/aolserver/ I do not know, who the owner of these repos is. Cloning these repos and to convert these to git is no rocket science, but one needs write permissions in preferable the "aolserver" bitbucket repo to make this public. all the best -g On 03.04.20 18:13, Andrew Piskorski wrote: > Can someone with write access also convert the AOLserver Mercurial > repositories on BitBucket to Git, so we still have that stuff for > historical reference, once BitBucket deletes all the Mercurial > repositories? > > https://bitbucket.org/aolserver/aolserver-40x/src/default/ > https://bitbucket.org/aolserver/aolserver/src/default/ > > Or is there a better repository for the old AOLserver code somewhere > else? I see some stuff on GitHub, but I'm not sure how that compares > to the BitBucket repositories. > > https://github.com/aolserver/aolserver > https://github.com/aolserver/aolserver.github.com > https://github.com/aolserver/nsoracle > https://aolserver.github.io/2010/04/aolserver-on-github/ > https://github.com/OldsSourcesBackups/AolWebServer > |
From: Andrew P. <at...@pi...> - 2020-04-03 16:31:30
|
Can someone with write access also convert the AOLserver Mercurial repositories on BitBucket to Git, so we still have that stuff for historical reference, once BitBucket deletes all the Mercurial repositories? https://bitbucket.org/aolserver/aolserver-40x/src/default/ https://bitbucket.org/aolserver/aolserver/src/default/ Or is there a better repository for the old AOLserver code somewhere else? I see some stuff on GitHub, but I'm not sure how that compares to the BitBucket repositories. https://github.com/aolserver/aolserver https://github.com/aolserver/aolserver.github.com https://github.com/aolserver/nsoracle https://aolserver.github.io/2010/04/aolserver-on-github/ https://github.com/OldsSourcesBackups/AolWebServer -- Andrew Piskorski <at...@pi...> |
From: Ben B. <tek...@ya...> - 2020-03-30 12:45:33
|
Hi Gustaf, You're right. The kernel hardening features are set, including: xdcpmer@harvesp-agah:~$ sudo dmesg | grep "Execute Disable" [ 0.000000] NX (Execute Disable) protection: active This particular one appears to be at the BIOS level instead of sysctl. And yet apache2 works. There *should be* some way for this feature to learn about Naviserver, too. I'm guessing nsd needs to be distributed in the OS via regular package distribution in order to work with this feature. I'm talking with GCP about possibility of turning off the feature or offering an unshielded Ubuntu image. All the internal Ubuntu offerings are shielded[2]. I am pivoting to FreeBSD in the interim. Thank you for the link and your time! NaviServer cheers, Ben 2. https://cloud.google.com/shielded-vm On 3/29/20 8:48 PM, Gustaf Neumann wrote: > Dear Ben > > Not sure, what is going on these Google Cloud platforms. > With Ubuntu 18.04.4 LTS + Linux 5.3.0, i see no problems. > Maybe, some of the Kernel hardening parameters [1] are set? > > -gn > > $ uname -a > Linux cigoos 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > $ sudo /usr/local/ns/bin/nsd -f -u nsadmin -g nsadmin -t /usr/local/ns/conf/nsd-config.tcl > ... > [30/Mar/2020:03:25:11][32118.7f376effd700][-driver:nssock:0-] Notice: nssock:0: listening on [0.0.0.0]:8080 > [30/Mar/2020:03:25:11][32118.7f377a268740][-main-] Notice: nsmain: NaviServer/4.99.19 (tar-4.99.19) running > > > [1]https://www.kmotoko.com/articles/linux-hardening-kernel-parameters-with-sysctl/ > > On 30.03.20 00:33, Ben Brink via naviserver-devel wrote: >> Hi, >> >> With vTPM and monitoring turned off (and server rebooted), nsd still >> doesn't boot due to same error for both ports and either a specific ip >> number or 0.0.0.0. >> >> I suspect this is some overzealous latent TPM/monitoring or related >> permissions as I had a similar issue earlier this year running VMs in >> GNS3 on linux 5.0.0+ which I worked around instead of resolving, >> because there seemed to be a bunch of upstream changes in that area of >> the kernel that may have fixed the GNS3 issue if I could wait for them >> to reach standard Linux releases. >> >> cheers, >> Ben >> >> On 3/29/20 3:17 PM, Ben Brink via naviserver-devel wrote: >>> Hi, >>> >>> Also, GCP says that vTPM and integrity monitoring options are enabled >>> by default, but that Secure Boot is not.[1] >>> >>> 1. >>> https://cloud.google.com/compute/docs/instances/modifying-shielded-vm#modify-shielded-vm-instance >>> >>> >>> I'm going to turn off vTPM, and see if that's enough to get nsd to bind. >>> >>> >>> >>> >>> On 3/29/20 2:59 PM, Ben Brink via naviserver-devel wrote: >>>> Hi, >>>> >>>> NaviServer fails to bind on start up to port 8000 or 80 and a >>>> specific ip number or as 0.0.0.0. >>>> >>>> The errors are identical. See log snip below. >>>> >>>> For diagnostic purposes, I tried apache2 on 80. It works with: >>>> >>>> # systemctl start apache2 >>>> >>>> # systemctl start oacs-5-9-1 >>>> Job for oacs-5-9-1.service failed because the control process exited >>>> with error code. >>>> See "systemctl status oacs-5-9-1.service" and "journalctl -xe" for >>>> details. >>>> # uname -a Linux harvesp-agah 5.0.0-1033-gcp #34-Ubuntu SMP Tue Mar >>>> 3 04:36:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux >>>> >>>> The first error in the log occurs after startup. >>>> >>>> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nssock:0: >>>> adding virtual host entry for host <private.biz:80> location: >>>> http://private.biz:80 mapped to server: oacs-5-9-1 >>>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: >>>> starting >>>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: >>>> bind operation on sock 15 lead to error: Cannot assign requested >>>> address >>>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] >>>> Warning: bind on: SockAddr family AF_INET, ip x.x.x.x, port 80 >>>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: >>>> Ns_SockBinderListen: sendmsg() failed: sent 53 bytes, 'Cannot assign >>>> requested address' >>>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: >>>> nssock:0: failed to listen on [x.x.x.x]:80: Cannot assign requested >>>> address >>>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] >>>> Warning: could no bind any of the following addresses, stopping this >>>> driver: x.x.x.x >>>> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: >>>> NaviServer/4.99.19 (tar-4.99.19) running >>>> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: >>>> security info: uid=1002, euid=1002, gid=1003, egid=1003 >>>> [29/Mar/2020:05:50:33][2926.7fad6d353700][-sched-] Notice: sched: >>>> starting >>>> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Fatal: nsmain: >>>> can't communicate with parent process, nwrite -1, error: Broken pipe >>>> (parent process was probably killed) >>>> >>>> This is on an ubuntu image on GCP: >>>> >>>> ubuntu-minimal-1804-bionic-v20200317 >>>> Description >>>> Canonical, Ubuntu, 18.04 LTS Minimal, amd64 bionic minimal image >>>> built on 2020-03-17, supports Shielded VM features >>>> >>>> I'm guessing it's some kind of vTPM/kernel security issue, since >>>> extra security features were added to the linux kernel at version5.0.0. >>>> >>>> Any suggestions on how to get NaviServer to bind / pass the security >>>> challenge? >>>> >>>> kind regards, >>>> Ben >>>> >>>> >>>> >>>> _______________________________________________ >>>> naviserver-devel mailing list >>>> nav...@li... >>>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >>> >>> >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> >> >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel > |
From: Gustaf N. <ne...@wu...> - 2020-03-30 03:48:29
|
Dear Ben Not sure, what is going on these Google Cloud platforms. With Ubuntu 18.04.4 LTS + Linux 5.3.0, i see no problems. Maybe, some of the Kernel hardening parameters [1] are set? -gn $ uname -a Linux cigoos 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux $ sudo /usr/local/ns/bin/nsd -f -u nsadmin -g nsadmin -t /usr/local/ns/conf/nsd-config.tcl ... [30/Mar/2020:03:25:11][32118.7f376effd700][-driver:nssock:0-] Notice: nssock:0: listening on [0.0.0.0]:8080 [30/Mar/2020:03:25:11][32118.7f377a268740][-main-] Notice: nsmain: NaviServer/4.99.19 (tar-4.99.19) running [1] https://www.kmotoko.com/articles/linux-hardening-kernel-parameters-with-sysctl/ On 30.03.20 00:33, Ben Brink via naviserver-devel wrote: > Hi, > > With vTPM and monitoring turned off (and server rebooted), nsd still > doesn't boot due to same error for both ports and either a specific ip > number or 0.0.0.0. > > I suspect this is some overzealous latent TPM/monitoring or related > permissions as I had a similar issue earlier this year running VMs in > GNS3 on linux 5.0.0+ which I worked around instead of resolving, > because there seemed to be a bunch of upstream changes in that area of > the kernel that may have fixed the GNS3 issue if I could wait for them > to reach standard Linux releases. > > cheers, > Ben > > On 3/29/20 3:17 PM, Ben Brink via naviserver-devel wrote: >> Hi, >> >> Also, GCP says that vTPM and integrity monitoring options are enabled >> by default, but that Secure Boot is not.[1] >> >> 1. >> https://cloud.google.com/compute/docs/instances/modifying-shielded-vm#modify-shielded-vm-instance >> >> >> I'm going to turn off vTPM, and see if that's enough to get nsd to bind. >> >> >> >> >> On 3/29/20 2:59 PM, Ben Brink via naviserver-devel wrote: >>> Hi, >>> >>> NaviServer fails to bind on start up to port 8000 or 80 and a >>> specific ip number or as 0.0.0.0. >>> >>> The errors are identical. See log snip below. >>> >>> For diagnostic purposes, I tried apache2 on 80. It works with: >>> >>> # systemctl start apache2 >>> >>> # systemctl start oacs-5-9-1 >>> Job for oacs-5-9-1.service failed because the control process exited >>> with error code. >>> See "systemctl status oacs-5-9-1.service" and "journalctl -xe" for >>> details. >>> # uname -a Linux harvesp-agah 5.0.0-1033-gcp #34-Ubuntu SMP Tue Mar >>> 3 04:36:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux >>> >>> The first error in the log occurs after startup. >>> >>> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nssock:0: >>> adding virtual host entry for host <private.biz:80> location: >>> http://private.biz:80 mapped to server: oacs-5-9-1 >>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: >>> starting >>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: >>> bind operation on sock 15 lead to error: Cannot assign requested >>> address >>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] >>> Warning: bind on: SockAddr family AF_INET, ip x.x.x.x, port 80 >>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: >>> Ns_SockBinderListen: sendmsg() failed: sent 53 bytes, 'Cannot assign >>> requested address' >>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: >>> nssock:0: failed to listen on [x.x.x.x]:80: Cannot assign requested >>> address >>> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] >>> Warning: could no bind any of the following addresses, stopping this >>> driver: x.x.x.x >>> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: >>> NaviServer/4.99.19 (tar-4.99.19) running >>> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: >>> security info: uid=1002, euid=1002, gid=1003, egid=1003 >>> [29/Mar/2020:05:50:33][2926.7fad6d353700][-sched-] Notice: sched: >>> starting >>> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Fatal: nsmain: >>> can't communicate with parent process, nwrite -1, error: Broken pipe >>> (parent process was probably killed) >>> >>> This is on an ubuntu image on GCP: >>> >>> ubuntu-minimal-1804-bionic-v20200317 >>> Description >>> Canonical, Ubuntu, 18.04 LTS Minimal, amd64 bionic minimal image >>> built on 2020-03-17, supports Shielded VM features >>> >>> I'm guessing it's some kind of vTPM/kernel security issue, since >>> extra security features were added to the linux kernel at version5.0.0. >>> >>> Any suggestions on how to get NaviServer to bind / pass the security >>> challenge? >>> >>> kind regards, >>> Ben >>> >>> >>> >>> _______________________________________________ >>> naviserver-devel mailing list >>> nav...@li... >>> https://lists.sourceforge.net/lists/listinfo/naviserver-devel >> >> >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Ben B. <tek...@ya...> - 2020-03-29 22:33:19
|
Hi, With vTPM and monitoring turned off (and server rebooted), nsd still doesn't boot due to same error for both ports and either a specific ip number or 0.0.0.0. I suspect this is some overzealous latent TPM/monitoring or related permissions as I had a similar issue earlier this year running VMs in GNS3 on linux 5.0.0+ which I worked around instead of resolving, because there seemed to be a bunch of upstream changes in that area of the kernel that may have fixed the GNS3 issue if I could wait for them to reach standard Linux releases. cheers, Ben On 3/29/20 3:17 PM, Ben Brink via naviserver-devel wrote: > Hi, > > Also, GCP says that vTPM and integrity monitoring options are enabled by > default, but that Secure Boot is not.[1] > > 1. > https://cloud.google.com/compute/docs/instances/modifying-shielded-vm#modify-shielded-vm-instance > > > I'm going to turn off vTPM, and see if that's enough to get nsd to bind. > > > > > On 3/29/20 2:59 PM, Ben Brink via naviserver-devel wrote: >> Hi, >> >> NaviServer fails to bind on start up to port 8000 or 80 and a specific >> ip number or as 0.0.0.0. >> >> The errors are identical. See log snip below. >> >> For diagnostic purposes, I tried apache2 on 80. It works with: >> >> # systemctl start apache2 >> >> # systemctl start oacs-5-9-1 >> Job for oacs-5-9-1.service failed because the control process exited >> with error code. >> See "systemctl status oacs-5-9-1.service" and "journalctl -xe" for >> details. >> # uname -a Linux harvesp-agah 5.0.0-1033-gcp #34-Ubuntu SMP Tue Mar 3 >> 04:36:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux >> >> The first error in the log occurs after startup. >> >> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nssock:0: >> adding virtual host entry for host <private.biz:80> location: >> http://private.biz:80 mapped to server: oacs-5-9-1 >> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: >> starting >> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: >> bind operation on sock 15 lead to error: Cannot assign requested address >> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Warning: >> bind on: SockAddr family AF_INET, ip x.x.x.x, port 80 >> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: >> Ns_SockBinderListen: sendmsg() failed: sent 53 bytes, 'Cannot assign >> requested address' >> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: >> nssock:0: failed to listen on [x.x.x.x]:80: Cannot assign requested >> address >> [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Warning: >> could no bind any of the following addresses, stopping this driver: >> x.x.x.x >> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: >> NaviServer/4.99.19 (tar-4.99.19) running >> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: >> security info: uid=1002, euid=1002, gid=1003, egid=1003 >> [29/Mar/2020:05:50:33][2926.7fad6d353700][-sched-] Notice: sched: >> starting >> [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Fatal: nsmain: can't >> communicate with parent process, nwrite -1, error: Broken pipe (parent >> process was probably killed) >> >> This is on an ubuntu image on GCP: >> >> ubuntu-minimal-1804-bionic-v20200317 >> Description >> Canonical, Ubuntu, 18.04 LTS Minimal, amd64 bionic minimal image built >> on 2020-03-17, supports Shielded VM features >> >> I'm guessing it's some kind of vTPM/kernel security issue, since extra >> security features were added to the linux kernel at version5.0.0. >> >> Any suggestions on how to get NaviServer to bind / pass the security >> challenge? >> >> kind regards, >> Ben >> >> >> >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Ben B. <tek...@ya...> - 2020-03-29 22:18:02
|
Hi, Also, GCP says that vTPM and integrity monitoring options are enabled by default, but that Secure Boot is not.[1] 1. https://cloud.google.com/compute/docs/instances/modifying-shielded-vm#modify-shielded-vm-instance I'm going to turn off vTPM, and see if that's enough to get nsd to bind. On 3/29/20 2:59 PM, Ben Brink via naviserver-devel wrote: > Hi, > > NaviServer fails to bind on start up to port 8000 or 80 and a specific > ip number or as 0.0.0.0. > > The errors are identical. See log snip below. > > For diagnostic purposes, I tried apache2 on 80. It works with: > > # systemctl start apache2 > > # systemctl start oacs-5-9-1 > Job for oacs-5-9-1.service failed because the control process exited > with error code. > See "systemctl status oacs-5-9-1.service" and "journalctl -xe" for details. > # uname -a Linux harvesp-agah 5.0.0-1033-gcp #34-Ubuntu SMP Tue Mar 3 > 04:36:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > The first error in the log occurs after startup. > > [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nssock:0: > adding virtual host entry for host <private.biz:80> location: > http://private.biz:80 mapped to server: oacs-5-9-1 > [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: > starting > [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: > bind operation on sock 15 lead to error: Cannot assign requested address > [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Warning: > bind on: SockAddr family AF_INET, ip x.x.x.x, port 80 > [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: > Ns_SockBinderListen: sendmsg() failed: sent 53 bytes, 'Cannot assign > requested address' > [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: > nssock:0: failed to listen on [x.x.x.x]:80: Cannot assign requested address > [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Warning: > could no bind any of the following addresses, stopping this driver: x.x.x.x > [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: > NaviServer/4.99.19 (tar-4.99.19) running > [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: > security info: uid=1002, euid=1002, gid=1003, egid=1003 > [29/Mar/2020:05:50:33][2926.7fad6d353700][-sched-] Notice: sched: starting > [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Fatal: nsmain: can't > communicate with parent process, nwrite -1, error: Broken pipe (parent > process was probably killed) > > This is on an ubuntu image on GCP: > > ubuntu-minimal-1804-bionic-v20200317 > Description > Canonical, Ubuntu, 18.04 LTS Minimal, amd64 bionic minimal image built > on 2020-03-17, supports Shielded VM features > > I'm guessing it's some kind of vTPM/kernel security issue, since extra > security features were added to the linux kernel at version5.0.0. > > Any suggestions on how to get NaviServer to bind / pass the security > challenge? > > kind regards, > Ben > > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Ben B. <tek...@ya...> - 2020-03-29 21:59:56
|
Hi, NaviServer fails to bind on start up to port 8000 or 80 and a specific ip number or as 0.0.0.0. The errors are identical. See log snip below. For diagnostic purposes, I tried apache2 on 80. It works with: # systemctl start apache2 # systemctl start oacs-5-9-1 Job for oacs-5-9-1.service failed because the control process exited with error code. See "systemctl status oacs-5-9-1.service" and "journalctl -xe" for details. # uname -a Linux harvesp-agah 5.0.0-1033-gcp #34-Ubuntu SMP Tue Mar 3 04:36:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux The first error in the log occurs after startup. [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nssock:0: adding virtual host entry for host <private.biz:80> location: http://private.biz:80 mapped to server: oacs-5-9-1 [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: starting [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Notice: bind operation on sock 15 lead to error: Cannot assign requested address [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Warning: bind on: SockAddr family AF_INET, ip x.x.x.x, port 80 [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: Ns_SockBinderListen: sendmsg() failed: sent 53 bytes, 'Cannot assign requested address' [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Error: nssock:0: failed to listen on [x.x.x.x]:80: Cannot assign requested address [29/Mar/2020:05:50:33][2926.7fad622be700][-driver:nssock:0-] Warning: could no bind any of the following addresses, stopping this driver: x.x.x.x [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: NaviServer/4.99.19 (tar-4.99.19) running [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Notice: nsmain: security info: uid=1002, euid=1002, gid=1003, egid=1003 [29/Mar/2020:05:50:33][2926.7fad6d353700][-sched-] Notice: sched: starting [29/Mar/2020:05:50:33][2926.7fad7081c740][-main-] Fatal: nsmain: can't communicate with parent process, nwrite -1, error: Broken pipe (parent process was probably killed) This is on an ubuntu image on GCP: ubuntu-minimal-1804-bionic-v20200317 Description Canonical, Ubuntu, 18.04 LTS Minimal, amd64 bionic minimal image built on 2020-03-17, supports Shielded VM features I'm guessing it's some kind of vTPM/kernel security issue, since extra security features were added to the linux kernel at version5.0.0. Any suggestions on how to get NaviServer to bind / pass the security challenge? kind regards, Ben |
From: Brian F. <Bri...@qu...> - 2020-03-24 12:56:16
|
Right. It might just be my Hiberno English, as my usage of the word "issue" wasn't meant to indicate a flaw. In this case, I intended it to mean the source of the behaviour I was seeing. Anyway, I'll look into upgrading OpenSSL. many thanks! Brian ________________________________ From: Gustaf Neumann <ne...@wu...> Sent: Tuesday 24 March 2020 07:53 To: nav...@li... <nav...@li...> Subject: Re: [naviserver-devel] nsssl: error loading ciphers This message's attachments contains at least one web link. This is often used for phishing attempts. Please only interact with this attachment if you know its source and that the content is safe. If in doubt, confirm the legitimacy with the sender by phone. i would not call it an "issue" (this has often a connotation of a flaw), but it is not supported yet in the version you are using. You need probably OpenSSL 1.1.1 or newer. You can check as well ciphers -v | grep TLSv1.3 to see the proper Cipher Suite Names (IANA) usable for e.g. TLSv1.3 -gn On 23.03.20 18:08, Brian Fenton wrote: Hi Gustaf Ah this is an OpenSSL issue, not Naviserver. No, those ciphers are not listed when I type openssl list -cipher-algorithms This is on Windows 2012 Server and OpenSSL version is OpenSSL 1.1.0e 16 Feb 2017 thanks Brian ________________________________ From: Gustaf Neumann <ne...@wu...><mailto:ne...@wu...> Sent: Monday 23 March 2020 17:02 To: nav...@li...<mailto:nav...@li...> <nav...@li...><mailto:nav...@li...> Subject: Re: [naviserver-devel] nsssl: error loading ciphers This message's attachments contains at least one web link. This is often used for phishing attempts. Please only interact with this attachment if you know its source and that the content is safe. If in doubt, confirm the legitimacy with the sender by phone. Dear Brian, What version of OpenSSL are you using on what OS? Are these ciphers available in this OpenSSL implementation? openssl list -cipher-algorithms It might be possible, that the same version of OpenSSL has on different platforms/distributions different ciphers included. All the best -g On 23.03.20 17:23, Brian Fenton wrote: error loading ciphers: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 _______________________________________________ naviserver-devel mailing list nav...@li...<mailto:nav...@li...> https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Gustaf N. <ne...@wu...> - 2020-03-24 07:54:10
|
i would not call it an "issue" (this has often a connotation of a flaw), but it is not supported yet in the version you are using. You need probably OpenSSL 1.1.1 or newer. You can check as well ciphers -v | grep TLSv1.3 to see the proper Cipher Suite Names (IANA) usable for e.g. TLSv1.3 -gn On 23.03.20 18:08, Brian Fenton wrote: > Hi Gustaf > > Ah this is an OpenSSL issue, not Naviserver. No, those ciphers are not > listed when I type openssl list -cipher-algorithms > > This is on Windows 2012 Server and OpenSSL version is > *OpenSSL 1.1.0e 16 Feb 2017* > > thanks > Brian > > ------------------------------------------------------------------------ > *From:* Gustaf Neumann <ne...@wu...> > *Sent:* Monday 23 March 2020 17:02 > *To:* nav...@li... > <nav...@li...> > *Subject:* Re: [naviserver-devel] nsssl: error loading ciphers > > > > This message's attachments contains at least one web link. This is > often used for phishing attempts. Please only interact with this > attachment if you know its source and that the content is safe. If in > doubt, confirm the legitimacy with the sender by phone. > > > Dear Brian, > > What version of OpenSSL are you using on what OS? > Are these ciphers available in this OpenSSL implementation? > > openssl list -cipher-algorithms > It might be possible, that the same version of OpenSSL has on different > platforms/distributions different ciphers included. > > All the best > -g > > On 23.03.20 17:23, Brian Fenton wrote: >> error loading ciphers: >> TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 > > > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Brian F. <Bri...@qu...> - 2020-03-23 21:44:39
|
Hi Gustaf Ah this is an OpenSSL issue, not Naviserver. No, those ciphers are not listed when I type openssl list -cipher-algorithms This is on Windows 2012 Server and OpenSSL version is OpenSSL 1.1.0e 16 Feb 2017 thanks Brian ________________________________ From: Gustaf Neumann <ne...@wu...> Sent: Monday 23 March 2020 17:02 To: nav...@li... <nav...@li...> Subject: Re: [naviserver-devel] nsssl: error loading ciphers This message's attachments contains at least one web link. This is often used for phishing attempts. Please only interact with this attachment if you know its source and that the content is safe. If in doubt, confirm the legitimacy with the sender by phone. Dear Brian, What version of OpenSSL are you using on what OS? Are these ciphers available in this OpenSSL implementation? openssl list -cipher-algorithms It might be possible, that the same version of OpenSSL has on different platforms/distributions different ciphers included. All the best -g On 23.03.20 17:23, Brian Fenton wrote: error loading ciphers: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 |
From: Gustaf N. <ne...@wu...> - 2020-03-23 17:02:52
|
Dear Brian, What version of OpenSSL are you using on what OS? Are these ciphers available in this OpenSSL implementation? openssl list -cipher-algorithms It might be possible, that the same version of OpenSSL has on different platforms/distributions different ciphers included. All the best -g On 23.03.20 17:23, Brian Fenton wrote: > error loading ciphers: > TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 |
From: Brian F. <Bri...@qu...> - 2020-03-23 16:39:08
|
Hi I have been trying to change the nsssl ciphers that we use. As an experiment, I took the recommended configurations from Mozilla here https://wiki.mozilla.org/Security/Server_Side_TLS Mozilla's recommended "Intermediate" configuration loaded perfectly and is working well e.g. set ciphers "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384" set protocols "TLSv1.2:TLSv1.3" ns_section "ns/server/${server}/module/nsssl" ns_param address $address ns_param port $httpsport ns_param hostname $hostname ns_param ciphers $ciphers ns_param protocols $protocols But when I try the "modern" configuration, e.g. set ciphers "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256" set protocols "TLSv1.3" I get this error: [23/Mar/2020:15:36:17][6864.28fc][-main:dev-] Error: nsssl: error loading ciphers: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 Do I need to do something else to get Naviserver to support this? thanks Brian |
From: THORPE M. <ta...@me...> - 2020-03-17 11:03:45
|
Gustaf, Thank you for the follow up and the direction. I will implement you suggestion. So far the problem has not reoccurred. Best regards, Thorpe > On Mar 14, 2020, at 3:22 PM, Gustaf Neumann <ne...@wu...> wrote: > > Dear Thorpe, > > the commit [1] introduces more more log severity named "Debug(timeout)", > which causes - when switched on - the server to write timeout related > entries to the system log, such this can be used as well on busy servers. > Just turn it on with > > ns_logctl severity Debug(timeout) on > > (e.g. at the end of the config file, or via other means such as nsshell), > and it should lead you to the place where the problem occurs. > > Hope, this helps > > -g > > [1] https://bitbucket.org/naviserver/naviserver/commits/d1c8de59f417b833ff1a8b3b61bf1aea63ac5a94 <https://bitbucket.org/naviserver/naviserver/commits/d1c8de59f417b833ff1a8b3b61bf1aea63ac5a94> > On 11.03.20 17:39, THORPE MAYES via naviserver-devel wrote: >> Gustaf, >> >> Thank you very much for your response. >> >> The server stands alone. >> >> This has happened twice in the past 10 days. Never before for the last 20 years (unless I induced it). >> >> I looked at the cpu usage, which tells me if we are in a never-ending loop. All was well there. >> >> I looked at the logs thinking that the event was related to something. I cannot see any relationship. >> >> I am just serving web pages built using tcl that utilize data generated from a database. There is nothing I do that is sophisticated. >> >> For the moment I am monitoring the issue. We will see what happens. >> >> Again, thank you for your response (and your work on the naviserver project). >> >> Thorpe >> >>> On Mar 11, 2020, at 9:18 AM, Gustaf Neumann <ne...@wu... <mailto:ne...@wu...>> wrote: >>> >>> Dear Thorpe, >>> >>> i just checked the source code, and found two situations, when the server >>> returns a 503 HTTP status: >>> >>> a) The Tcl code issues a "ns_returnunavailable" >>> b) The Tcl-/ADP-request ends in a NS_TIMEOUT >>> >>> I would exclude (a) for now. (b) can happen e.g. when >>> one uses NaviServer as a reverse proxy to some backend host, >>> but the backend host does not answer. We checked our logs >>> on the busy servers over the last weeks, but could trace the >>> few 503 errors to cases, where the backend server was rebooted. >>> >>> it is possible to intensify the tracing of NaviServer in such cases, >>> but it would certainly be good to learn more about your >>> situation.... Can you check, if there is some unresponsible >>> backend server is involved in your case? >>> >>> all the best >>> >>> -g >>> >>> On 10.03.20 20:12, THORPE MAYES via naviserver-devel wrote: >>>> HI, >>>> >>>> I am getting this error: >>>> >>>> Service Unavailable >>>> The server is temporarily unable to service your request. Please try again later. >>>> NaviServer/4.99.19 on >>>> >>>> Restarting the server software fixes the issue, but I need a better solution. >>>> >>>> What causes this? How can I detect when the server is in this state? >>>> >>>> Thank you, >>>> > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel |
From: Gustaf N. <ne...@wu...> - 2020-03-14 20:22:35
|
Dear Thorpe, the commit [1] introduces more more log severity named "Debug(timeout)", which causes - when switched on - the server to write timeout related entries to the system log, such this can be used as well on busy servers. Just turn it on with ns_logctl severity Debug(timeout) on (e.g. at the end of the config file, or via other means such as nsshell), and it should lead you to the place where the problem occurs. Hope, this helps -g [1] https://bitbucket.org/naviserver/naviserver/commits/d1c8de59f417b833ff1a8b3b61bf1aea63ac5a94 On 11.03.20 17:39, THORPE MAYES via naviserver-devel wrote: > Gustaf, > > Thank you very much for your response. > > The server stands alone. > > This has happened twice in the past 10 days. Never before for the last > 20 years (unless I induced it). > > I looked at the cpu usage, which tells me if we are in a never-ending > loop. All was well there. > > I looked at the logs thinking that the event was related to something. > I cannot see any relationship. > > I am just serving web pages built using tcl that utilize data > generated from a database. There is nothing I do that is sophisticated. > > For the moment I am monitoring the issue. We will see what happens. > > Again, thank you for your response (and your work on the naviserver > project). > > Thorpe > >> On Mar 11, 2020, at 9:18 AM, Gustaf Neumann <ne...@wu... >> <mailto:ne...@wu...>> wrote: >> >> Dear Thorpe, >> >> i just checked the source code, and found two situations, when the server >> returns a 503 HTTP status: >> >> a) The Tcl code issues a "ns_returnunavailable" >> b) The Tcl-/ADP-request ends in a NS_TIMEOUT >> >> I would exclude (a) for now. (b) can happen e.g. when >> one uses NaviServer as a reverse proxy to some backend host, >> but the backend host does not answer. We checked our logs >> on the busy servers over the last weeks, but could trace the >> few 503 errors to cases, where the backend server was rebooted. >> >> it is possible to intensify the tracing of NaviServer in such cases, >> but it would certainly be good to learn more about your >> situation.... Can you check, if there is some unresponsible >> backend server is involved in your case? >> >> all the best >> >> -g >> >> On 10.03.20 20:12, THORPE MAYES via naviserver-devel wrote: >>> >>> >>> HI, >>> >>> I am getting this error: >>> >>> Service Unavailable >>> The server is temporarily unable to service your request. Please try >>> again later. >>> /NaviServer/4.99.19 on / >>> >>> Restarting the server software fixes the issue, but I need a better >>> solution. >>> >>> What causes this? How can I detect when the server is in this state? >>> >>> Thank you, >>> |