cgiwrap-users Mailing List for CGIWrap
Brought to you by:
nneul
Menu
▾
▴
cgiwrap-users
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(21) |
Sep
(23) |
Oct
(4) |
Nov
(15) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(5) |
Feb
(19) |
Mar
(19) |
Apr
(13) |
May
(12) |
Jun
(23) |
Jul
(6) |
Aug
(16) |
Sep
(6) |
Oct
(31) |
Nov
(23) |
Dec
(28) |
| 2002 |
Jan
(4) |
Feb
(9) |
Mar
(6) |
Apr
(23) |
May
(29) |
Jun
(16) |
Jul
(10) |
Aug
(41) |
Sep
(16) |
Oct
(8) |
Nov
(7) |
Dec
(7) |
| 2003 |
Jan
(13) |
Feb
(30) |
Mar
(6) |
Apr
(12) |
May
(23) |
Jun
(12) |
Jul
(11) |
Aug
(20) |
Sep
|
Oct
|
Nov
(10) |
Dec
(8) |
| 2004 |
Jan
(1) |
Feb
(11) |
Mar
(3) |
Apr
(10) |
May
(6) |
Jun
|
Jul
(3) |
Aug
(4) |
Sep
(3) |
Oct
(9) |
Nov
(2) |
Dec
|
| 2005 |
Jan
(7) |
Feb
|
Mar
(7) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(12) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(14) |
Dec
|
| 2008 |
Jan
(5) |
Feb
(10) |
Mar
|
Apr
(12) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
|
From: Nathan N. <nn...@ne...> - 2013-12-06 14:03:34
|
It's up on sf.net now. 2.9.1 -- Nathan On 12/06/2013 02:43 AM, snehal wrote: > Nathan, > > Thank you so much for your support. > I did build the tar on ppc64le platform, and does build fine. > > I have a small query here , would you keep this tar at dropbox location , or you would delete after some time ? > Since I would be giving the same link to distro guys, and they would be picking it from here. > > > Thanks, > Snehal > > > On 12/05/2013 07:48 PM, Nathan Neulinger wrote: >> Try the dropbox url again... I've told it to replace the config.guess/sub with latest from git since they are >> reasonably accessible as individual files. >> >> -- Nathan >> >> On 12/05/2013 03:16 AM, snehal wrote: >>> Hi Nathan, >>> >>> I tried to build the tar provided by you on ppc64le, however I see that config.guess file changes are missing for >>> ppc64le in the tar provided by you. >>> Config.guess file is available at >>> >>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD >>> >>> ----Or---- >>> I can send you patch for config.guess, let me know your preference. >>> >>> After adding config.guess patch for ppc64le support to the tar provided by you, I see all following files are generated. >>> >>> /*lib*# ls >>> libcrack.a libcrack.so libcrack.so.2.9.0 >>> libcrack.la libcrack.so.2 python2.7 >>> >>> /*share*# ls >>> cracklib locale >>> >>> /*include*# ls >>> crack.h packer.h >>> >>> /*sbin*# ls >>> cracklib-check cracklib-packer create-cracklib-dict >>> cracklib-format cracklib-unpacker >>> >>> It would be great if you incorporate config.guess changes and release tar... >>> >>> Awaiting your reply >>> >>> Thanks, >>> Snehal >>> >>> >>> On 12/03/2013 07:47 PM, Nathan Neulinger wrote: >>>> This tarball was generated with a "current" Fedora 20 (not even released yet) host with libtool/autoconf/etc. pieces >>>> as distributed on that platform. >>>> >>>> https://dl.dropboxusercontent.com/u/33773121/2013-12-03/cracklib-2.9.0.tar.gz >>>> >>>> Please see if it works for you. If that tarball DOES work for you, I'll be happy to do a new release with that build >>>> environment. >>>> >>>> If it doesn't, I don't think I'm going to be integrating the changes you've requested as I'm not interested in making >>>> the packaging of cracklib dependent on pieces that aren't present in current distributions or creating a tarball that >>>> can't be reproduced without developers jumping through extra hoops. >>>> >>>> If you are packaging yourself, I would suggest just adding the 'regen with your preferred/updated libtool/etc' as part >>>> of that packaging, but until those changes are included/accepted by mainstream linux distributions, they won't be >>>> included here. >>>> >>>> -- Nathan >>>> >>>> On 12/03/2013 12:16 AM, snehal wrote: >>>>> Hi Nathan, >>>>> >>>>> This is a gentle reminder to spin pkg with new config.guess and libtool. >>>>> >>>>> As per your suggestion, I did checkout SVN repo and did ./configure, make , make install >>>>> which did work fine on ppc64le platform. You may see details in my previous mail. >>>>> >>>>> Awaiting new tar from you with ppc64le support >>>>> >>>>> >>>>> Thanks in advance, >>>>> Snehal >>>>> >>>>> >>>>> >>>>> >>>>> On 11/18/2013 04:22 PM, snehal wrote: >>>>>> >>>>>> Hi Nathan, >>>>>> >>>>>> I did take SVN repo >>>>>> svn checkout svn://svn.code.sf.net/p/cracklib/code/trunk/cracklib >>>>>> >>>>>> Then did run autogen.sh , which generated new configuration file which supports ppc64le. >>>>>> Did >>>>>> ./configure >>>>>> make >>>>>> make install >>>>>> >>>>>> I see following output with new libtool version >>>>>> >>>>>> 1. Folders created >>>>>> /svn_cracklib# ls >>>>>> cracklib cracklib.tar *include lib sbin share* >>>>>> 2. Binaries created >>>>>> /**sbin**# ls >>>>>> cracklib-check cracklib-packer create-cracklib-dict >>>>>> cracklib-format cracklib-unpacker >>>>>> 3. /**share**# ls >>>>>> cracklib locale >>>>>> 4. /**lib**# ls >>>>>> libcrack.a libcrack.la libcrack.so libcrack.so.2 libcrack.so.2.9.0 >>>>>> 5. /**include**# ls >>>>>> crack.h packer.h >>>>>> >>>>>> Let me know if this is what you would see >>>>>> If yes, then you may spin the pkg again with new libtool and release tar for us. >>>>>> >>>>>> >>>>>> Snehal >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/14/2013 08:09 PM, Nathan Neulinger wrote: >>>>>>> Since you have the upstream tools (libtool / autoconf) installed with the updated components, have you tried just >>>>>>> running autogen.sh in an svn checkout of cracklib and see if it all works? >>>>>>> >>>>>>> svn checkout svn://svn.code.sf.net/p/cracklib/code/trunk/cracklib >>>>>>> >>>>>>> Problem is - I don't actually copy in those files manually - I just use the generated ones from autoconf/autoheader >>>>>>> installed on my devel box. >>>>>>> >>>>>>> I'll try to find some time to install latest autoconf/libtool on my box (currently fc17 so a bit downlevel) and see >>>>>>> if I can generate a tarball that will work for you, but would be good for you to run a test from svn first just >>>>>>> to be >>>>>>> certain it will solve the problem for you. >>>>>>> >>>>>>> -- Nathan >>>>>>> >>>>>>> On 11/14/2013 06:39 AM, snehal wrote: >>>>>>>> Hi Nathan, >>>>>>>> >>>>>>>> Alpha release of libtool is available at following location >>>>>>>> ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz (1.6MB) >>>>>>>> ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz (920KB) >>>>>>>> >>>>>>>> It would be great if you can install this new libtool which supports ppc64le, >>>>>>>> and spin the pkg and let us know the new tar availability. We can test it on ppc64le architecture for you. >>>>>>>> >>>>>>>> Currently I used http://sourceforge.net/projects/cracklib/files/latest/download/cracklib-2.9.0.tar.gz >>>>>>>> Which does not have ppc64le support. >>>>>>>> >>>>>>>> Also, >>>>>>>> Latest config.guess and config.sub w/ ppc64le fix is available @ >>>>>>>> >>>>>>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and >>>>>>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD respectively. >>>>>>>> >>>>>>>> Thanks in advance, >>>>>>>> Snehal >>>>>>>> >>>>>>>> >>>>>>>> On 10/23/2013 06:11 PM, Nathan Neulinger wrote: >>>>>>>>> I'm the current maintainer for cracklib, however if you have patches to libtool.m4/config.guess - those need to go >>>>>>>>> upstream to the maintainers of those packages - they are not part of cracklib package. If you're talking about >>>>>>>>> changes >>>>>>>>> to configure.ac, those would go to this package. >>>>>>>>> >>>>>>>>> cracklib repo is still svn based on sourceforge project page. >>>>>>>>> >>>>>>>>> -- Nathan >>>>>>>>> >>>>>>>>> On 10/23/2013 01:51 AM, snehal wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I found your name in AUTHORS file of cracklib2 tarball. I tried search upstream source mailing list for this pkg, >>>>>>>>>> however I could not find one for upstream source. >>>>>>>>>> >>>>>>>>>> We are in the process of adding support for new arch (ppc64le) and as part of that wanted to send patches for >>>>>>>>>> libtool.m4/config.guess or configure as appropriate. In that context, I wanted to confirm the below >>>>>>>>>> 1) Should we send patches to you or there is some other mailing list? >>>>>>>>>> 2) I could not find git repo. Only debian git repo found >>>>>>>>>> http:///git/.debian.org/?p=pkg-cracklib/pkg-cracklib./git >>>>>>>>>> /Could you please point me to upstream git repo ?/ >>>>>>>>>> / 3) Who is the maintainer for this pkg ? >>>>>>>>>> >>>>>>>>>> Appreciate your response >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Snehal >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
|
From: Nathan N. <nn...@ne...> - 2013-12-06 13:45:32
|
I'll release this on SF... post-replacing just the config.guess/config.sub is self contained enough that I'm willing to have that in the release. -- Nathan On 12/06/2013 02:43 AM, snehal wrote: > Nathan, > > Thank you so much for your support. > I did build the tar on ppc64le platform, and does build fine. > > I have a small query here , would you keep this tar at dropbox location , or you would delete after some time ? > Since I would be giving the same link to distro guys, and they would be picking it from here. > > > Thanks, > Snehal > > > On 12/05/2013 07:48 PM, Nathan Neulinger wrote: >> Try the dropbox url again... I've told it to replace the config.guess/sub with latest from git since they are >> reasonably accessible as individual files. >> >> -- Nathan >> >> On 12/05/2013 03:16 AM, snehal wrote: >>> Hi Nathan, >>> >>> I tried to build the tar provided by you on ppc64le, however I see that config.guess file changes are missing for >>> ppc64le in the tar provided by you. >>> Config.guess file is available at >>> >>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD >>> >>> ----Or---- >>> I can send you patch for config.guess, let me know your preference. >>> >>> After adding config.guess patch for ppc64le support to the tar provided by you, I see all following files are generated. >>> >>> /*lib*# ls >>> libcrack.a libcrack.so libcrack.so.2.9.0 >>> libcrack.la libcrack.so.2 python2.7 >>> >>> /*share*# ls >>> cracklib locale >>> >>> /*include*# ls >>> crack.h packer.h >>> >>> /*sbin*# ls >>> cracklib-check cracklib-packer create-cracklib-dict >>> cracklib-format cracklib-unpacker >>> >>> It would be great if you incorporate config.guess changes and release tar... >>> >>> Awaiting your reply >>> >>> Thanks, >>> Snehal >>> >>> >>> On 12/03/2013 07:47 PM, Nathan Neulinger wrote: >>>> This tarball was generated with a "current" Fedora 20 (not even released yet) host with libtool/autoconf/etc. pieces >>>> as distributed on that platform. >>>> >>>> https://dl.dropboxusercontent.com/u/33773121/2013-12-03/cracklib-2.9.0.tar.gz >>>> >>>> Please see if it works for you. If that tarball DOES work for you, I'll be happy to do a new release with that build >>>> environment. >>>> >>>> If it doesn't, I don't think I'm going to be integrating the changes you've requested as I'm not interested in making >>>> the packaging of cracklib dependent on pieces that aren't present in current distributions or creating a tarball that >>>> can't be reproduced without developers jumping through extra hoops. >>>> >>>> If you are packaging yourself, I would suggest just adding the 'regen with your preferred/updated libtool/etc' as part >>>> of that packaging, but until those changes are included/accepted by mainstream linux distributions, they won't be >>>> included here. >>>> >>>> -- Nathan >>>> >>>> On 12/03/2013 12:16 AM, snehal wrote: >>>>> Hi Nathan, >>>>> >>>>> This is a gentle reminder to spin pkg with new config.guess and libtool. >>>>> >>>>> As per your suggestion, I did checkout SVN repo and did ./configure, make , make install >>>>> which did work fine on ppc64le platform. You may see details in my previous mail. >>>>> >>>>> Awaiting new tar from you with ppc64le support >>>>> >>>>> >>>>> Thanks in advance, >>>>> Snehal >>>>> >>>>> >>>>> >>>>> >>>>> On 11/18/2013 04:22 PM, snehal wrote: >>>>>> >>>>>> Hi Nathan, >>>>>> >>>>>> I did take SVN repo >>>>>> svn checkout svn://svn.code.sf.net/p/cracklib/code/trunk/cracklib >>>>>> >>>>>> Then did run autogen.sh , which generated new configuration file which supports ppc64le. >>>>>> Did >>>>>> ./configure >>>>>> make >>>>>> make install >>>>>> >>>>>> I see following output with new libtool version >>>>>> >>>>>> 1. Folders created >>>>>> /svn_cracklib# ls >>>>>> cracklib cracklib.tar *include lib sbin share* >>>>>> 2. Binaries created >>>>>> /**sbin**# ls >>>>>> cracklib-check cracklib-packer create-cracklib-dict >>>>>> cracklib-format cracklib-unpacker >>>>>> 3. /**share**# ls >>>>>> cracklib locale >>>>>> 4. /**lib**# ls >>>>>> libcrack.a libcrack.la libcrack.so libcrack.so.2 libcrack.so.2.9.0 >>>>>> 5. /**include**# ls >>>>>> crack.h packer.h >>>>>> >>>>>> Let me know if this is what you would see >>>>>> If yes, then you may spin the pkg again with new libtool and release tar for us. >>>>>> >>>>>> >>>>>> Snehal >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/14/2013 08:09 PM, Nathan Neulinger wrote: >>>>>>> Since you have the upstream tools (libtool / autoconf) installed with the updated components, have you tried just >>>>>>> running autogen.sh in an svn checkout of cracklib and see if it all works? >>>>>>> >>>>>>> svn checkout svn://svn.code.sf.net/p/cracklib/code/trunk/cracklib >>>>>>> >>>>>>> Problem is - I don't actually copy in those files manually - I just use the generated ones from autoconf/autoheader >>>>>>> installed on my devel box. >>>>>>> >>>>>>> I'll try to find some time to install latest autoconf/libtool on my box (currently fc17 so a bit downlevel) and see >>>>>>> if I can generate a tarball that will work for you, but would be good for you to run a test from svn first just >>>>>>> to be >>>>>>> certain it will solve the problem for you. >>>>>>> >>>>>>> -- Nathan >>>>>>> >>>>>>> On 11/14/2013 06:39 AM, snehal wrote: >>>>>>>> Hi Nathan, >>>>>>>> >>>>>>>> Alpha release of libtool is available at following location >>>>>>>> ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz (1.6MB) >>>>>>>> ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz (920KB) >>>>>>>> >>>>>>>> It would be great if you can install this new libtool which supports ppc64le, >>>>>>>> and spin the pkg and let us know the new tar availability. We can test it on ppc64le architecture for you. >>>>>>>> >>>>>>>> Currently I used http://sourceforge.net/projects/cracklib/files/latest/download/cracklib-2.9.0.tar.gz >>>>>>>> Which does not have ppc64le support. >>>>>>>> >>>>>>>> Also, >>>>>>>> Latest config.guess and config.sub w/ ppc64le fix is available @ >>>>>>>> >>>>>>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and >>>>>>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD respectively. >>>>>>>> >>>>>>>> Thanks in advance, >>>>>>>> Snehal >>>>>>>> >>>>>>>> >>>>>>>> On 10/23/2013 06:11 PM, Nathan Neulinger wrote: >>>>>>>>> I'm the current maintainer for cracklib, however if you have patches to libtool.m4/config.guess - those need to go >>>>>>>>> upstream to the maintainers of those packages - they are not part of cracklib package. If you're talking about >>>>>>>>> changes >>>>>>>>> to configure.ac, those would go to this package. >>>>>>>>> >>>>>>>>> cracklib repo is still svn based on sourceforge project page. >>>>>>>>> >>>>>>>>> -- Nathan >>>>>>>>> >>>>>>>>> On 10/23/2013 01:51 AM, snehal wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I found your name in AUTHORS file of cracklib2 tarball. I tried search upstream source mailing list for this pkg, >>>>>>>>>> however I could not find one for upstream source. >>>>>>>>>> >>>>>>>>>> We are in the process of adding support for new arch (ppc64le) and as part of that wanted to send patches for >>>>>>>>>> libtool.m4/config.guess or configure as appropriate. In that context, I wanted to confirm the below >>>>>>>>>> 1) Should we send patches to you or there is some other mailing list? >>>>>>>>>> 2) I could not find git repo. Only debian git repo found >>>>>>>>>> http:///git/.debian.org/?p=pkg-cracklib/pkg-cracklib./git >>>>>>>>>> /Could you please point me to upstream git repo ?/ >>>>>>>>>> / 3) Who is the maintainer for this pkg ? >>>>>>>>>> >>>>>>>>>> Appreciate your response >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Snehal >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
|
From: Nathan N. <nn...@ne...> - 2013-12-05 14:27:02
|
Try the dropbox url again... I've told it to replace the config.guess/sub with latest from git since they are reasonably accessible as individual files. -- Nathan On 12/05/2013 03:16 AM, snehal wrote: > Hi Nathan, > > I tried to build the tar provided by you on ppc64le, however I see that config.guess file changes are missing for > ppc64le in the tar provided by you. > Config.guess file is available at > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD > > ----Or---- > I can send you patch for config.guess, let me know your preference. > > After adding config.guess patch for ppc64le support to the tar provided by you, I see all following files are generated. > > /*lib*# ls > libcrack.a libcrack.so libcrack.so.2.9.0 > libcrack.la libcrack.so.2 python2.7 > > /*share*# ls > cracklib locale > > /*include*# ls > crack.h packer.h > > /*sbin*# ls > cracklib-check cracklib-packer create-cracklib-dict > cracklib-format cracklib-unpacker > > It would be great if you incorporate config.guess changes and release tar... > > Awaiting your reply > > Thanks, > Snehal > > > On 12/03/2013 07:47 PM, Nathan Neulinger wrote: >> This tarball was generated with a "current" Fedora 20 (not even released yet) host with libtool/autoconf/etc. pieces >> as distributed on that platform. >> >> https://dl.dropboxusercontent.com/u/33773121/2013-12-03/cracklib-2.9.0.tar.gz >> >> Please see if it works for you. If that tarball DOES work for you, I'll be happy to do a new release with that build >> environment. >> >> If it doesn't, I don't think I'm going to be integrating the changes you've requested as I'm not interested in making >> the packaging of cracklib dependent on pieces that aren't present in current distributions or creating a tarball that >> can't be reproduced without developers jumping through extra hoops. >> >> If you are packaging yourself, I would suggest just adding the 'regen with your preferred/updated libtool/etc' as part >> of that packaging, but until those changes are included/accepted by mainstream linux distributions, they won't be >> included here. >> >> -- Nathan >> >> On 12/03/2013 12:16 AM, snehal wrote: >>> Hi Nathan, >>> >>> This is a gentle reminder to spin pkg with new config.guess and libtool. >>> >>> As per your suggestion, I did checkout SVN repo and did ./configure, make , make install >>> which did work fine on ppc64le platform. You may see details in my previous mail. >>> >>> Awaiting new tar from you with ppc64le support >>> >>> >>> Thanks in advance, >>> Snehal >>> >>> >>> >>> >>> On 11/18/2013 04:22 PM, snehal wrote: >>>> >>>> Hi Nathan, >>>> >>>> I did take SVN repo >>>> svn checkout svn://svn.code.sf.net/p/cracklib/code/trunk/cracklib >>>> >>>> Then did run autogen.sh , which generated new configuration file which supports ppc64le. >>>> Did >>>> ./configure >>>> make >>>> make install >>>> >>>> I see following output with new libtool version >>>> >>>> 1. Folders created >>>> /svn_cracklib# ls >>>> cracklib cracklib.tar *include lib sbin share* >>>> 2. Binaries created >>>> /**sbin**# ls >>>> cracklib-check cracklib-packer create-cracklib-dict >>>> cracklib-format cracklib-unpacker >>>> 3. /**share**# ls >>>> cracklib locale >>>> 4. /**lib**# ls >>>> libcrack.a libcrack.la libcrack.so libcrack.so.2 libcrack.so.2.9.0 >>>> 5. /**include**# ls >>>> crack.h packer.h >>>> >>>> Let me know if this is what you would see >>>> If yes, then you may spin the pkg again with new libtool and release tar for us. >>>> >>>> >>>> Snehal >>>> >>>> >>>> >>>> >>>> On 11/14/2013 08:09 PM, Nathan Neulinger wrote: >>>>> Since you have the upstream tools (libtool / autoconf) installed with the updated components, have you tried just >>>>> running autogen.sh in an svn checkout of cracklib and see if it all works? >>>>> >>>>> svn checkout svn://svn.code.sf.net/p/cracklib/code/trunk/cracklib >>>>> >>>>> Problem is - I don't actually copy in those files manually - I just use the generated ones from autoconf/autoheader >>>>> installed on my devel box. >>>>> >>>>> I'll try to find some time to install latest autoconf/libtool on my box (currently fc17 so a bit downlevel) and see >>>>> if I can generate a tarball that will work for you, but would be good for you to run a test from svn first just to be >>>>> certain it will solve the problem for you. >>>>> >>>>> -- Nathan >>>>> >>>>> On 11/14/2013 06:39 AM, snehal wrote: >>>>>> Hi Nathan, >>>>>> >>>>>> Alpha release of libtool is available at following location >>>>>> ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz (1.6MB) >>>>>> ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz (920KB) >>>>>> >>>>>> It would be great if you can install this new libtool which supports ppc64le, >>>>>> and spin the pkg and let us know the new tar availability. We can test it on ppc64le architecture for you. >>>>>> >>>>>> Currently I used http://sourceforge.net/projects/cracklib/files/latest/download/cracklib-2.9.0.tar.gz >>>>>> Which does not have ppc64le support. >>>>>> >>>>>> Also, >>>>>> Latest config.guess and config.sub w/ ppc64le fix is available @ >>>>>> >>>>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and >>>>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD respectively. >>>>>> >>>>>> Thanks in advance, >>>>>> Snehal >>>>>> >>>>>> >>>>>> On 10/23/2013 06:11 PM, Nathan Neulinger wrote: >>>>>>> I'm the current maintainer for cracklib, however if you have patches to libtool.m4/config.guess - those need to go >>>>>>> upstream to the maintainers of those packages - they are not part of cracklib package. If you're talking about >>>>>>> changes >>>>>>> to configure.ac, those would go to this package. >>>>>>> >>>>>>> cracklib repo is still svn based on sourceforge project page. >>>>>>> >>>>>>> -- Nathan >>>>>>> >>>>>>> On 10/23/2013 01:51 AM, snehal wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I found your name in AUTHORS file of cracklib2 tarball. I tried search upstream source mailing list for this pkg, >>>>>>>> however I could not find one for upstream source. >>>>>>>> >>>>>>>> We are in the process of adding support for new arch (ppc64le) and as part of that wanted to send patches for >>>>>>>> libtool.m4/config.guess or configure as appropriate. In that context, I wanted to confirm the below >>>>>>>> 1) Should we send patches to you or there is some other mailing list? >>>>>>>> 2) I could not find git repo. Only debian git repo found >>>>>>>> http:///git/.debian.org/?p=pkg-cracklib/pkg-cracklib./git >>>>>>>> /Could you please point me to upstream git repo ?/ >>>>>>>> / 3) Who is the maintainer for this pkg ? >>>>>>>> >>>>>>>> Appreciate your response >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Snehal >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
|
From: Nathan N. <nn...@ne...> - 2013-12-03 14:48:26
|
This tarball was generated with a "current" Fedora 20 (not even released yet) host with libtool/autoconf/etc. pieces as distributed on that platform. https://dl.dropboxusercontent.com/u/33773121/2013-12-03/cracklib-2.9.0.tar.gz Please see if it works for you. If that tarball DOES work for you, I'll be happy to do a new release with that build environment. If it doesn't, I don't think I'm going to be integrating the changes you've requested as I'm not interested in making the packaging of cracklib dependent on pieces that aren't present in current distributions or creating a tarball that can't be reproduced without developers jumping through extra hoops. If you are packaging yourself, I would suggest just adding the 'regen with your preferred/updated libtool/etc' as part of that packaging, but until those changes are included/accepted by mainstream linux distributions, they won't be included here. -- Nathan On 12/03/2013 12:16 AM, snehal wrote: > Hi Nathan, > > This is a gentle reminder to spin pkg with new config.guess and libtool. > > As per your suggestion, I did checkout SVN repo and did ./configure, make , make install > which did work fine on ppc64le platform. You may see details in my previous mail. > > Awaiting new tar from you with ppc64le support > > > Thanks in advance, > Snehal > > > > > On 11/18/2013 04:22 PM, snehal wrote: >> >> Hi Nathan, >> >> I did take SVN repo >> svn checkout svn://svn.code.sf.net/p/cracklib/code/trunk/cracklib >> >> Then did run autogen.sh , which generated new configuration file which supports ppc64le. >> Did >> ./configure >> make >> make install >> >> I see following output with new libtool version >> >> 1. Folders created >> /svn_cracklib# ls >> cracklib cracklib.tar *include lib sbin share* >> 2. Binaries created >> /**sbin**# ls >> cracklib-check cracklib-packer create-cracklib-dict >> cracklib-format cracklib-unpacker >> 3. /**share**# ls >> cracklib locale >> 4. /**lib**# ls >> libcrack.a libcrack.la libcrack.so libcrack.so.2 libcrack.so.2.9.0 >> 5. /**include**# ls >> crack.h packer.h >> >> Let me know if this is what you would see >> If yes, then you may spin the pkg again with new libtool and release tar for us. >> >> >> Snehal >> >> >> >> >> On 11/14/2013 08:09 PM, Nathan Neulinger wrote: >>> Since you have the upstream tools (libtool / autoconf) installed with the updated components, have you tried just >>> running autogen.sh in an svn checkout of cracklib and see if it all works? >>> >>> svn checkout svn://svn.code.sf.net/p/cracklib/code/trunk/cracklib >>> >>> Problem is - I don't actually copy in those files manually - I just use the generated ones from autoconf/autoheader >>> installed on my devel box. >>> >>> I'll try to find some time to install latest autoconf/libtool on my box (currently fc17 so a bit downlevel) and see >>> if I can generate a tarball that will work for you, but would be good for you to run a test from svn first just to be >>> certain it will solve the problem for you. >>> >>> -- Nathan >>> >>> On 11/14/2013 06:39 AM, snehal wrote: >>>> Hi Nathan, >>>> >>>> Alpha release of libtool is available at following location >>>> ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.gz (1.6MB) >>>> ftp://alpha.gnu.org/gnu/libtool/libtool-2.4.2.418.tar.xz (920KB) >>>> >>>> It would be great if you can install this new libtool which supports ppc64le, >>>> and spin the pkg and let us know the new tar availability. We can test it on ppc64le architecture for you. >>>> >>>> Currently I used http://sourceforge.net/projects/cracklib/files/latest/download/cracklib-2.9.0.tar.gz >>>> Which does not have ppc64le support. >>>> >>>> Also, >>>> Latest config.guess and config.sub w/ ppc64le fix is available @ >>>> >>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and >>>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD respectively. >>>> >>>> Thanks in advance, >>>> Snehal >>>> >>>> >>>> On 10/23/2013 06:11 PM, Nathan Neulinger wrote: >>>>> I'm the current maintainer for cracklib, however if you have patches to libtool.m4/config.guess - those need to go >>>>> upstream to the maintainers of those packages - they are not part of cracklib package. If you're talking about changes >>>>> to configure.ac, those would go to this package. >>>>> >>>>> cracklib repo is still svn based on sourceforge project page. >>>>> >>>>> -- Nathan >>>>> >>>>> On 10/23/2013 01:51 AM, snehal wrote: >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> I found your name in AUTHORS file of cracklib2 tarball. I tried search upstream source mailing list for this pkg, >>>>>> however I could not find one for upstream source. >>>>>> >>>>>> We are in the process of adding support for new arch (ppc64le) and as part of that wanted to send patches for >>>>>> libtool.m4/config.guess or configure as appropriate. In that context, I wanted to confirm the below >>>>>> 1) Should we send patches to you or there is some other mailing list? >>>>>> 2) I could not find git repo. Only debian git repo found >>>>>> http:///git/.debian.org/?p=pkg-cracklib/pkg-cracklib./git >>>>>> /Could you please point me to upstream git repo ?/ >>>>>> / 3) Who is the maintainer for this pkg ? >>>>>> >>>>>> Appreciate your response >>>>>> >>>>>> Thanks, >>>>>> Snehal >>>>>> >>>>>> >>>>> >>>> >>> >> > -- ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
|
From: Mark M. <mar...@um...> - 2013-08-09 12:00:24
|
On August 8, 2013 23:24 , Tim Gustafson <tj...@uc...> wrote: > > We use AFS for out user home directories. I'd like CGI scripts to run > under each user's own account. Is there a way to configure CGIWrap to > use keytabs to get the same access to the user's data that they have > when they log in themselves? Or is there a better way to do this? > It is ancient and would need significant work to be ported forward to the current version of CGIWrap, but is the following what you are looking for? http://sourceforge.net/p/cgiwrap/mailman/message/1702179/ I can send you the patch privately, if it's something you're willing to wrestle with (the link at the beginning of the message no longer works). If I recall correctly, the patch was not accepted into CGIWrap. -- Mark Montague LSA IT Advocacy and Research Support University of Michigan mar...@um... |
|
From: Tim G. <tj...@uc...> - 2013-08-09 03:52:48
|
Hi, We use AFS for out user home directories. I'd like CGI scripts to run under each user's own account. Is there a way to configure CGIWrap to use keytabs to get the same access to the user's data that they have when they log in themselves? Or is there a better way to do this? |
|
From: Ali G. <gha...@gm...> - 2011-08-22 13:29:36
|
now I see. thank you. On Mon, Aug 22, 2011 at 5:56 PM, Nathan Neulinger <nn...@ne...>wrote: > No - the whole point is to run the scripts with individual user level > permissions. You probably should seek some assistance from a knowledgeable > admin for how to do it securely. > > For limited admin functionality, you most likely will want to use sudo with > a NOPASSWD entry for the SPECIFIC commands that you want to use from the cgi > script, but even with that you need to be very careful with how you do it or > you're going to open up security holes. > > -- Nathan > > > On 08/22/2011 08:23 AM, Ali Ghanavatian wrote: > >> allright, correct me if I'm wrong: I can't run a perl/script which >> executes "/sbin/*" stuff like "/sbin/iptables" using >> this wrapper, unless I change the owner of all "cgi-bin/*" scripts to >> "root". >> >> >> On Mon, Aug 22, 2011 at 5:47 PM, Nathan Neulinger <nn...@ne...<mailto: >> nn...@ne...>> wrote: >> >> Mainly stuff like whether the script is setuid, or has improper >> permissions (i.e. 777) or isn't owned by the same >> user as the account it would be running as. >> >> -- Nathan >> >> On 08/19/2011 08:55 PM, Ali Ghanavatian wrote: >> >> Hello world! >> I just found cgiwrapper, I was reading this page. at the end of >> first paragraph it says "...In addition, several >> security checks are performed on the script, which will not be >> executed if any checks fail. " >> >> I counld'nt find anything about those "security checks". i'd >> appreciate it if you guys help me with a link or >> any details. >> >> -- >> Sincerely >> A. Ghanavatian <http://www.google.com/__**profiles/ghanavatian.ali<http://www.google.com/__profiles/ghanavatian.ali>< >> http://www.google.com/**profiles/ghanavatian.ali<http://www.google.com/profiles/ghanavatian.ali> >> >> >> >> >> >> >> ------------------------------**__----------------------------** >> --__------------------ >> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >> user administration capabilities and model configuration. Take >> the hassle out of deploying and managing Subversion and the >> tools developers use with it. http://p.sf.net/sfu/wandisco-_** >> _d2d-2 <http://p.sf.net/sfu/wandisco-__d2d-2> < >> http://p.sf.net/sfu/wandisco-**d2d-2 <http://p.sf.net/sfu/wandisco-d2d-2> >> > >> >> >> >> ______________________________**___________________ >> cgiwrap-users mailing list >> cgiwrap-users@lists.__sourcefo**rge.net <http://sourceforge.net><mailto: >> cgiwrap-users@lists.**sourceforge.net<cgi...@li...> >> > >> >> https://lists.sourceforge.net/**__lists/listinfo/cgiwrap-users<https://lists.sourceforge.net/__lists/listinfo/cgiwrap-users> >> <https://lists.sourceforge.**net/lists/listinfo/cgiwrap-**users<https://lists.sourceforge.net/lists/listinfo/cgiwrap-users> >> > >> >> >> -- >> ------------------------------**__----------------------------**-- >> Nathan Neulinger nn...@ne... <mailto:nn...@ne...> >> >> Neulinger Consulting (573) 612-1412 >> >> >> >> >> -- >> Sincerely >> A. Ghanavatian <http://www.google.com/**profiles/ghanavatian.ali<http://www.google.com/profiles/ghanavatian.ali> >> > >> >> > -- > ------------------------------**------------------------------ > > Nathan Neulinger nn...@ne... > Neulinger Consulting (573) 612-1412 > -- Sincerely A. Ghanavatian <http://www.google.com/profiles/ghanavatian.ali> |
|
From: Nathan N. <nn...@ne...> - 2011-08-22 13:26:58
|
No - the whole point is to run the scripts with individual user level permissions. You probably should seek some assistance from a knowledgeable admin for how to do it securely. For limited admin functionality, you most likely will want to use sudo with a NOPASSWD entry for the SPECIFIC commands that you want to use from the cgi script, but even with that you need to be very careful with how you do it or you're going to open up security holes. -- Nathan On 08/22/2011 08:23 AM, Ali Ghanavatian wrote: > allright, correct me if I'm wrong: I can't run a perl/script which executes "/sbin/*" stuff like "/sbin/iptables" using > this wrapper, unless I change the owner of all "cgi-bin/*" scripts to "root". > > > On Mon, Aug 22, 2011 at 5:47 PM, Nathan Neulinger <nn...@ne... <mailto:nn...@ne...>> wrote: > > Mainly stuff like whether the script is setuid, or has improper permissions (i.e. 777) or isn't owned by the same > user as the account it would be running as. > > -- Nathan > > On 08/19/2011 08:55 PM, Ali Ghanavatian wrote: > > Hello world! > I just found cgiwrapper, I was reading this page. at the end of first paragraph it says "...In addition, several > security checks are performed on the script, which will not be executed if any checks fail. " > > I counld'nt find anything about those "security checks". i'd appreciate it if you guys help me with a link or > any details. > > -- > Sincerely > A. Ghanavatian <http://www.google.com/__profiles/ghanavatian.ali <http://www.google.com/profiles/ghanavatian.ali>> > > > > ------------------------------__------------------------------__------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-__d2d-2 <http://p.sf.net/sfu/wandisco-d2d-2> > > > > _________________________________________________ > cgiwrap-users mailing list > cgiwrap-users@lists.__sourceforge.net <mailto:cgi...@li...> > https://lists.sourceforge.net/__lists/listinfo/cgiwrap-users > <https://lists.sourceforge.net/lists/listinfo/cgiwrap-users> > > > -- > ------------------------------__------------------------------ > Nathan Neulinger nn...@ne... <mailto:nn...@ne...> > Neulinger Consulting (573) 612-1412 > > > > > -- > Sincerely > A. Ghanavatian <http://www.google.com/profiles/ghanavatian.ali> > -- ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
|
From: Ali G. <gha...@gm...> - 2011-08-22 13:23:56
|
allright, correct me if I'm wrong: I can't run a perl/script which executes "/sbin/*" stuff like "/sbin/iptables" using this wrapper, unless I change the owner of all "cgi-bin/*" scripts to "root". On Mon, Aug 22, 2011 at 5:47 PM, Nathan Neulinger <nn...@ne...>wrote: > Mainly stuff like whether the script is setuid, or has improper permissions > (i.e. 777) or isn't owned by the same user as the account it would be > running as. > > -- Nathan > > On 08/19/2011 08:55 PM, Ali Ghanavatian wrote: > >> Hello world! >> I just found cgiwrapper, I was reading this page. at the end of first >> paragraph it says "...In addition, several >> security checks are performed on the script, which will not be executed if >> any checks fail. " >> >> I counld'nt find anything about those "security checks". i'd appreciate it >> if you guys help me with a link or any details. >> >> -- >> Sincerely >> A. Ghanavatian <http://www.google.com/**profiles/ghanavatian.ali<http://www.google.com/profiles/ghanavatian.ali> >> > >> >> >> >> ------------------------------**------------------------------** >> ------------------ >> Get a FREE DOWNLOAD! and learn more about uberSVN rich system, >> user administration capabilities and model configuration. Take >> the hassle out of deploying and managing Subversion and the >> tools developers use with it. http://p.sf.net/sfu/wandisco-**d2d-2<http://p.sf.net/sfu/wandisco-d2d-2> >> >> >> >> ______________________________**_________________ >> cgiwrap-users mailing list >> cgiwrap-users@lists.**sourceforge.net<cgi...@li...> >> https://lists.sourceforge.net/**lists/listinfo/cgiwrap-users<https://lists.sourceforge.net/lists/listinfo/cgiwrap-users> >> > > -- > ------------------------------**------------------------------ > Nathan Neulinger nn...@ne... > Neulinger Consulting (573) 612-1412 > -- Sincerely A. Ghanavatian <http://www.google.com/profiles/ghanavatian.ali> |
|
From: Nathan N. <nn...@ne...> - 2011-08-22 13:17:47
|
Mainly stuff like whether the script is setuid, or has improper permissions (i.e. 777) or isn't owned by the same user as the account it would be running as. -- Nathan On 08/19/2011 08:55 PM, Ali Ghanavatian wrote: > Hello world! > I just found cgiwrapper, I was reading this page. at the end of first paragraph it says "...In addition, several > security checks are performed on the script, which will not be executed if any checks fail. " > > I counld'nt find anything about those "security checks". i'd appreciate it if you guys help me with a link or any details. > > -- > Sincerely > A. Ghanavatian <http://www.google.com/profiles/ghanavatian.ali> > > > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > > > > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users -- ------------------------------------------------------------ Nathan Neulinger nn...@ne... Neulinger Consulting (573) 612-1412 |
|
From: Ali G. <gha...@gm...> - 2011-08-20 01:56:22
|
Hello world! I just found cgiwrapper, I was reading this page. at the end of first paragraph it says "...In addition, several security checks are performed on the script, which will not be executed if any checks fail. " I counld'nt find anything about those "security checks". i'd appreciate it if you guys help me with a link or any details. -- Sincerely A. Ghanavatian <http://www.google.com/profiles/ghanavatian.ali> |
|
From: Harry R. <har...@mi...> - 2011-05-25 11:44:22
|
The RFC is pretty clear, though maybe you missed it. PHP and all other CGI/cgiwrap executables read CONTENT_LENGTH bytes from STDIN. There's a fairly old Perl CGI tutorial which covers the details: http://www.abiglime.com/webmaster/articles/cgi/021098.htm and is easily translatable to C. On 25 May 2011 12:01, maurizio beppo <fui...@gm...> wrote: > > Hi, i'm try to understand how message-body ( > http://www.faqs.org/rfcs/rfc3875.html) (like $_POST variable in php) is > passed to execv(). > > Example: > I have a data in a form, like this > <form method=POST> > <input type=text value="admin" name="login"> > <input type=pass value="123" name="passwd"> > etc... > </form> > > Cgiwrap make the environment (i put here the most important) > > ENV: 'HTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.68 Safari/534.24' > ENV: 'CONTENT_TYPE=application/x-www-form-urlencoded' > ENV: 'HTTP_ACCEPT=application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5' > > ENV: 'CONTENT_LENGTH=119' > ENV: 'SERVER_SOFTWARE=Apache/2.2.14 (Unix)' > ENV: 'SCRIPT_FILENAME=/drupal2/index.php' > ENV: 'REDIRECT_QUERY_STRING=q=node&destination=node' > ENV: 'REDIRECT_URL=/drupal2/index.php' > ENV: 'GATEWAY_INTERFACE=CGI/1.1' > ENV: 'SERVER_PROTOCOL=HTTP/1.0' > ENV: 'REQUEST_METHOD=POST' > ENV: 'QUERY_STRING=q=node&destination=node' > ENV: 'REQUEST_URI=/drupal2/?q=node&destination=node > > ENV: 'SCRIPT_NAME=/drupal2/index.php' > > > and after do somethig like > > execv("/path/php", {"/path/php", "/doc/index.php",NULL}) > > My problem is to understand: where is message-body ?? > i do this: > /* Execute the script */ > DEBUG_Msg("\n\n"); > DEBUG_Msg("Output of script follows:"); > DEBUG_Str("argv[0]:",Context.execPath); > DEBUG_Str("argv[0]:",Context.execArgv[0]); > DEBUG_Str("argv[1]:",Context.execArgv[1]); > DEBUG_Str("argv[2]:",Context.execArgv[2]); // is --> NULL > for(i = 0;*(environ+i);++i) > DEBUG_Str("ENV:",*(environ+i)); > DEBUG_Msg("====================================================="); > > and i can't find nothig about message-body in the environment. > > How you can see, CONTENT_LENGTH=119, and message-body is somethig like > login=admin&pass=123&other=etc > > How can php initialize his POST data ? > > Please, can you help me ? > > thank you very much > > > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users > > |
|
From: maurizio b. <fui...@gm...> - 2011-05-25 11:02:02
|
Hi, i'm try to understand how message-body ( http://www.faqs.org/rfcs/rfc3875.html) (like $_POST variable in php) is passed to execv(). Example: I have a data in a form, like this <form method=POST> <input type=text value="admin" name="login"> <input type=pass value="123" name="passwd"> etc... </form> Cgiwrap make the environment (i put here the most important) ENV: 'HTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.68 Safari/534.24' ENV: 'CONTENT_TYPE=application/x-www-form-urlencoded' ENV: 'HTTP_ACCEPT=application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5' ENV: 'CONTENT_LENGTH=119' ENV: 'SERVER_SOFTWARE=Apache/2.2.14 (Unix)' ENV: 'SCRIPT_FILENAME=/drupal2/index.php' ENV: 'REDIRECT_QUERY_STRING=q=node&destination=node' ENV: 'REDIRECT_URL=/drupal2/index.php' ENV: 'GATEWAY_INTERFACE=CGI/1.1' ENV: 'SERVER_PROTOCOL=HTTP/1.0' ENV: 'REQUEST_METHOD=POST' ENV: 'QUERY_STRING=q=node&destination=node' ENV: 'REQUEST_URI=/drupal2/?q=node&destination=node ENV: 'SCRIPT_NAME=/drupal2/index.php' and after do somethig like execv("/path/php", {"/path/php", "/doc/index.php",NULL}) My problem is to understand: where is message-body ?? i do this: /* Execute the script */ DEBUG_Msg("\n\n"); DEBUG_Msg("Output of script follows:"); DEBUG_Str("argv[0]:",Context.execPath); DEBUG_Str("argv[0]:",Context.execArgv[0]); DEBUG_Str("argv[1]:",Context.execArgv[1]); DEBUG_Str("argv[2]:",Context.execArgv[2]); // is --> NULL for(i = 0;*(environ+i);++i) DEBUG_Str("ENV:",*(environ+i)); DEBUG_Msg("====================================================="); and i can't find nothig about message-body in the environment. How you can see, CONTENT_LENGTH=119, and message-body is somethig like login=admin&pass=123&other=etc How can php initialize his POST data ? Please, can you help me ? thank you very much |
|
From: Neulinger, N. <nn...@ms...> - 2010-10-11 14:03:28
|
> I've read the docs on the website and I've got a few questions (some of > which > seem easy to me but I can't find an answer for!): > > * Does cgiwrap build itself into the source-code of apache, or is it an > external binary that is called by a content handler? External setuid binary. It gets installed into the cgi-bin directory configured in apache, which no one other than the server admin should have write access to. (This should be in the docs.) > * Are there any RPMs maintained for Centos 5? I don't believe so, as the specific configuration of cgiwrap will generally depend on the circumstances of the site, a one-size-fits-all RPM generally wouldn't be appropriate. > * Would it be easy to convert to an RPM? Sure, it's a pretty simple build if you wanted to do a custom RPM specific to your installation. Just start with a base spec file for another package and tweak as required. > If anyone can provide any help on this, it would be much appreciated! > > Kind regards, > > Matt > > ----------------------------------------------------------------------- > ------- > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating > great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users |
|
From: Matt W. <li...@tr...> - 2010-10-11 12:23:08
|
Hi all, I'm new to the list, so please feel free to point me in the direction of websites etc if you feel the content there is a better way for me to learn how all this works! I've read the docs on the website and I've got a few questions (some of which seem easy to me but I can't find an answer for!): * Does cgiwrap build itself into the source-code of apache, or is it an external binary that is called by a content handler? * Are there any RPMs maintained for Centos 5? * Would it be easy to convert to an RPM? If anyone can provide any help on this, it would be much appreciated! Kind regards, Matt |
|
From: Neulinger, N. <nn...@ms...> - 2010-04-28 18:34:44
|
Yes, I believe that is correct. -- Nathan ------------------------------------------------------------ Nathan Neulinger nn...@ms... Missouri S&T Information Technology (573) 612-1412 System Administrator - Principal KD0DMH > -----Original Message----- > From: Tim Gustafson [mailto:tj...@so...] > Sent: Wednesday, April 28, 2010 1:31 PM > To: Neulinger, Nathan > Cc: cgi...@li... > Subject: Re: [cgiwrap-users] Proper Use of --with-rlimit-* > Configuration Options > > > It's going to totally depend on what the users are doing and > > your particular system. I've seen perfectly reasonable CGI > > scripts spike to a hundred meg plus for split seconds. > > The limits I have set on my PHP scripts that are not controlled by > cgiwrap are 30 seconds and 128MB of RAM. So, would that be: > > --with-rlimit-cpu=30 --with-rlimit-data=134217728 > > Tim Gustafson > Baskin School of Engineering > UC Santa Cruz > tj...@so... > 831-459-5354 |
|
From: Tim G. <tj...@so...> - 2010-04-28 18:31:30
|
> It's going to totally depend on what the users are doing and > your particular system. I've seen perfectly reasonable CGI > scripts spike to a hundred meg plus for split seconds. The limits I have set on my PHP scripts that are not controlled by cgiwrap are 30 seconds and 128MB of RAM. So, would that be: --with-rlimit-cpu=30 --with-rlimit-data=134217728 Tim Gustafson Baskin School of Engineering UC Santa Cruz tj...@so... 831-459-5354 |
|
From: Neulinger, N. <nn...@ms...> - 2010-04-28 18:22:48
|
It's going to totally depend on what the users are doing and your particular system. I've seen perfectly reasonable CGI scripts spike to a hundred meg plus for split seconds. For documentation of the limits, 'man setrlimit' should give you useful information. -- Nathan ------------------------------------------------------------ Nathan Neulinger nn...@ms... Missouri S&T Information Technology (573) 612-1412 System Administrator - Principal KD0DMH > -----Original Message----- > From: Tim Gustafson [mailto:tj...@so...] > Sent: Wednesday, April 28, 2010 12:54 PM > To: cgi...@li... > Subject: [cgiwrap-users] Proper Use of --with-rlimit-* Configuration > Options > > Hi, > > I use cgiwrap to secure CGI scripts running in user's home directories > on a shared web server. I've had occasions where people have written > buggy CGI scripts that use up tons of RAM (in some cases 8GB or more) > and will run indefinitely (hours and hours) and I'd like to use the -- > with-rlimit-* options to fix that. However, I'm not all that familiar > with using the rlimit options, or using rlimit in general. > > I was wondering if anyone could recommend good settings for these: > > --with-rlimit-cpu > --with-rlimit-vmem > --with-rlimit-as > --with-rlimit-fsize > --with-rlimit-data > --with-rlimit-stack > --with-rlimit-core > --with-rlimit-rss > --with-rlimit-nproc > --with-rlimit-nofile > --with-rlimit-memlock > > I think I want --with-rlimit-cpu=30 but I really am not 100% clear on > the difference between all the different memory limits. What are some > sane numbers to use here for "average" user CGI scripts? > > Tim Gustafson > Baskin School of Engineering > UC Santa Cruz > tj...@so... > 831-459-5354 > > > ----------------------------------------------------------------------- > ------- > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users |
|
From: Tim G. <tj...@so...> - 2010-04-28 17:54:30
|
Hi, I use cgiwrap to secure CGI scripts running in user's home directories on a shared web server. I've had occasions where people have written buggy CGI scripts that use up tons of RAM (in some cases 8GB or more) and will run indefinitely (hours and hours) and I'd like to use the --with-rlimit-* options to fix that. However, I'm not all that familiar with using the rlimit options, or using rlimit in general. I was wondering if anyone could recommend good settings for these: --with-rlimit-cpu --with-rlimit-vmem --with-rlimit-as --with-rlimit-fsize --with-rlimit-data --with-rlimit-stack --with-rlimit-core --with-rlimit-rss --with-rlimit-nproc --with-rlimit-nofile --with-rlimit-memlock I think I want --with-rlimit-cpu=30 but I really am not 100% clear on the difference between all the different memory limits. What are some sane numbers to use here for "average" user CGI scripts? Tim Gustafson Baskin School of Engineering UC Santa Cruz tj...@so... 831-459-5354 |
|
From: Kent R. <in...@ke...> - 2010-03-13 20:22:05
|
I'm working on a shared host (with virtual hosting) that has cgiwrap installed. Trying to get the PHP scripts to execute a different version of PHP.
I do not have access to server config (httpd.conf, etc).
There are existing binaries on the server for the PHP version I want to use.
I've tried making a cgi wrapper for the PHP scripts, like how fastCGI wrappers are usually constructed:
* .htaccess has
AddHandler php-wrapper .php
Action php-wrapper /bin/wrapper.cgi
* wrapper.cgi has this code:
#!/usr/bin/sh
# without these headers, I get internal server error
echo "Content-type: text/html\n\n";
# The combination of variables is what I found would yield the
# required path to the incoming PHP script to be executed.
exec /path/to/php-cgi -q ${DOCUMENT_ROOT}${PATH_INFO} ${QUERY_STRING}
I've tried many different variations of the 'exec' line. Without 'exec', with just '-i' or '-v' as a parameter to php... But it either has a fatal error or gives me blank output.
The only thing that's yielded any expected results is '-h' parameter to PHP in the 'exec' line. I get the same help text that I would if I were using the command line.
I've tried recompiling cgiwrap using the new path/to/php, putting the binary in the public_html/bin directory, and changing the Action cgiwrap accordingly, but that resulted in a file not found error because the server concatenated the script path/filename onto the cgiwrap path.
Thanks for any ideas,
Kent
--
Kent Richards
510.292.7430
ke...@ke...
http://www.kentrichards.net
|
|
From: Trevor A. <as...@ta...> - 2009-09-22 17:50:02
|
I tried to post this to the fastcgi-developers list, but the confirmation
emails are bouncing. I hope someone here can help me debug my
configuration...
Does anyone know why I get a 404 when accessing a FastCgiServer via an alias
when using cgiwrap? The same configuration minus the FastCgiWrapper works. With
the FastCgiWrapper enabled, the server starts successfully, but all accesses to
the alias result in a 404.
Here is the configuration:
FastCgiWrapper /usr/lib/cgiwrap
FastCgiServer /opt/www/bin/fastcgi.pl -processes 3 \
-user www -group www \
-initial-env PATH_INFO=/www/bin/fastcgi.pl \
-initial-env REMOTE_ADDR=127.0.0.1
Alias /fastcgi/ /opt/www/bin/fastcgi.pl/
<Location /fastcgi>
Allow from all
</Location>
Like I said, the server starts successfully and I see debug output in the
apache error_log, but any attempts to access /fastcgi/ result in a 404. If I
remove the FastCgiWrapper configuration, the alias works.
Any help is appreciated.
Thanks,
Trevor
|
|
From: Neulinger, N. <nn...@ms...> - 2009-05-20 17:42:43
|
I would suggest running the script through cgiwrapd so you can see the debug trace content being returned. Once you have that working, you can switch back to regular cgiwrap. -- Nathan ------------------------------------------------------------ Nathan Neulinger nn...@ms... Missouri S&T Information Technology (573) 341-6679 System Administrator - Principal KD0DMH > -----Original Message----- > From: Martin Cassidy [mailto:fis...@gm...] > Sent: Wednesday, May 20, 2009 11:56 AM > To: cgi...@li... > Subject: [cgiwrap-users] PHP with Cgi Wrap > > I've been trying to work this out all afternoon but cannot. I've > installed cgiwrap ok, configuration ok and it works with .pl just fine > but php is another matter. I have configured php using the --enable- > discard-path which was ok, I've added the #!/usr/local/bin/php line to > the top of the php file im trying to run through cgiwrap but I am > geting an error 500. The error log reports the following: > > root index.php <NULL> 164.11.204.57 <NULL> ok Sun May > 10 22:50:38 2009 > > [Sun May 10 22:50:38 2009] [error] [client 164.11.204.57] Premature end > of script headers: cgiwrap > > Any help you can provide would be greatly apprechiated > > Thanks > Maritn |
|
From: Martin C. <fis...@gm...> - 2009-05-20 16:56:18
|
I've been trying to work this out all afternoon but cannot. I've installed cgiwrap ok, configuration ok and it works with .pl just fine but php is another matter. I have configured php using the --enable-discard-path which was ok, I've added the #!/usr/local/bin/php line to the top of the php file im trying to run through cgiwrap but I am geting an error 500. The error log reports the following: root index.php <NULL> 164.11.204.57 <NULL> ok Sun May 10 22:50:38 2009 [Sun May 10 22:50:38 2009] [error] [client 164.11.204.57] Premature end of script headers: cgiwrap Any help you can provide would be greatly apprechiated Thanks Maritn |
|
From: Jo R. <jr...@ne...> - 2008-11-24 21:52:24
|
You don't need to put cgiwrap in a scriptalias environment. I think you'll find it much easier to define cgiwrap as a handler. This way you can leave cgiwrap outside the document path. It works perfectly. On Nov 24, 2008, at 8:41 AM, k.s.guleesh wrote: > I have rolled my own cgiwrap config but I'm stumped at this point. > > > I have configured a virtual host with > ScriptAlias /cgi-bin/ /admin/public_html/cgi-bin/ > > and I have built the cgiwrap binary into /admin/public_html/cgi-bin/ > (I only want that virtual host to have access to it). > > > > Here's my cgiwrap output - > > Initializing Logging > Redirecting STDERR to STDOUT > > Setting SIGXCPU to default behaviour > > > Environment Variables: > QUERY_STRING: '' > SCRIPT_NAME: '/cgi-bin/cgiwrapd' > SCRIPT_FILENAME: '/admin/public_html/cgi-bin/cgiwrapd' > REDIRECT_URL: '<NULL>' > PATH_INFO: '/root/test.cgi' > PATH_TRANSLATED: '/admin/public_html/root/test.cgi' > REMOTE_USER: '<NULL>' > REMOTE_HOST: '<NULL>' > REMOTE_ADDR: '127.0.0.1' > > > Trying to extract user from PATH_INFO. > Retrieved User Name: 'root' > > User Data Retrieved: > UserID: 'root' > UID: '0' > GID: '0' > Home Dir: '/root' > Checking remote host information. > Checking user minimum uid. > Checking user shell. > Global Deny File: '/etc/cgiwrap/cgiwrap.deny' > Global Allow File: '/etc/cgiwrap/cgiwrap.allow' > > Checking Access Files: > Deny file exists: '/etc/cgiwrap/cgiwrap.deny' > Allow file exists: '/etc/cgiwrap/cgiwrap.allow' > Checking deny file for 'root' > Checking allow file for 'root' > Found 'root' > > > Processing user directory configuration file. > Using configured base directory. > > Script Base Directory: '/admin/public_html/cgi_bin' > > ***************** > * CGIWrap Error * > ***************** > > The specified user does not have a script directory set up > for execution of cgi scripts, or the directory permissions > prevent cgiwrap from using that directory. > > > Now I mapped root to that folder via the cgiwrap.userdir config so > I'm imagining it is perhaps to do with directory permissions which > are all 755 > I remember coming across some docs somewhere that explained the > permission checking process but I can't seem to find it now that I > need it. > > for completeness here are the ./configure options I used > ./configure --mandir=/usr/share/man \ > --infodir=/usr/share/info \ > --with-install-group=www-data --with-install-user=root \ > --with-local-doc-url=/doc/cgiwrap \ > --with-cgi-dir=public_html/cgi-bin --with-httpd-user=www-data \ > --with-minimum-uid=0 \ > --with-logging-file=/var/log/cgiwrap.log \ > --with-allow-file=/etc/cgiwrap/cgiwrap.allow \ > --with-deny-file=/etc/cgiwrap/cgiwrap.deny \ > --with-host-checking --with-check-shell \ > --with-rewrite=/etc/cgiwrap/cgiwrap.userdir \ > --with-quiet-errors \ > --with-install-dir=/admin/public_html/cgi-bin > > Any ideas ? > Cheers > A. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > cgiwrap-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgiwrap-users |
|
From: k.s.guleesh <k.s...@go...> - 2008-11-24 18:58:19
|
On further investigation moving my public_html folder and contents to /root and removing my mapping from cgiwrap.userdir has allowed the script to work. i.e letting cgiwrap resolve the user dir naturally and not mapping root:/admin/public_html/cgi-bin so my question becomes how to use cgiwrap.userdir to map root to cgi-bin location - are there some ./configure options I need to use ? A. On Mon, 2008-11-24 at 16:41 +0000, k.s.guleesh wrote: > Hi , > I have rolled my own cgiwrap config but I'm stumped at this point. > > > I have configured a virtual host with > ScriptAlias /cgi-bin/ /admin/public_html/cgi-bin/ > > and I have built the cgiwrap binary into /admin/public_html/cgi-bin/ > (I only want that virtual host to have access to it). > > > > Here's my cgiwrap output - > > Initializing Logging > Redirecting STDERR to STDOUT > > Setting SIGXCPU to default behaviour > > > Environment Variables: > QUERY_STRING: '' > SCRIPT_NAME: '/cgi-bin/cgiwrapd' > SCRIPT_FILENAME: '/admin/public_html/cgi-bin/cgiwrapd' > REDIRECT_URL: '<NULL>' > PATH_INFO: '/root/test.cgi' > PATH_TRANSLATED: '/admin/public_html/root/test.cgi' > REMOTE_USER: '<NULL>' > REMOTE_HOST: '<NULL>' > REMOTE_ADDR: '127.0.0.1' > > > Trying to extract user from PATH_INFO. > Retrieved User Name: 'root' > > User Data Retrieved: > UserID: 'root' > UID: '0' > GID: '0' > Home Dir: '/root' > Checking remote host information. > Checking user minimum uid. > Checking user shell. > Global Deny File: '/etc/cgiwrap/cgiwrap.deny' > Global Allow File: '/etc/cgiwrap/cgiwrap.allow' > > Checking Access Files: > Deny file exists: '/etc/cgiwrap/cgiwrap.deny' > Allow file exists: '/etc/cgiwrap/cgiwrap.allow' > Checking deny file for 'root' > Checking allow file for 'root' > Found 'root' > > > Processing user directory configuration file. > Using configured base directory. > > Script Base Directory: '/admin/public_html/cgi_bin' > > ***************** > * CGIWrap Error * > ***************** > > The specified user does not have a script directory set up > for execution of cgi scripts, or the directory permissions > prevent cgiwrap from using that directory. > > > Now I mapped root to that folder via the cgiwrap.userdir config so I'm imagining it is perhaps to do with directory permissions which are all 755 > I remember coming across some docs somewhere that explained the permission checking process but I can't seem to find it now that I need it. > > for completeness here are the ./configure options I used > ./configure --mandir=/usr/share/man \ > --infodir=/usr/share/info \ > --with-install-group=www-data --with-install-user=root \ > --with-local-doc-url=/doc/cgiwrap \ > --with-cgi-dir=public_html/cgi-bin --with-httpd-user=www-data \ > --with-minimum-uid=0 \ > --with-logging-file=/var/log/cgiwrap.log \ > --with-allow-file=/etc/cgiwrap/cgiwrap.allow \ > --with-deny-file=/etc/cgiwrap/cgiwrap.deny \ > --with-host-checking --with-check-shell \ > --with-rewrite=/etc/cgiwrap/cgiwrap.userdir \ > --with-quiet-errors \ > --with-install-dir=/admin/public_html/cgi-bin > > Any ideas ? > Cheers > A. |
2 messages has been excluded from this view by a project administrator.
