Thread: [Codestriker-user] CVS_RSH (cvs over :ext:/SSH), the state of states and selinux advice (while tes
Brought to you by:
sits
From: Jack P. <j-p...@ta...> - 2006-04-17 02:25:08
|
Howdy all, Yesterday I found a tool which is exactly the kind of thing I've been looking for (have desperately needed) for coordinating software development in/with our group. Yes, I found codestriker. My motivations are pretty much the same as David's original ones... sick of pointless meetings, sick of redundant and contradictory feedback on proposed patches, and having a tree full of changes that are going to get lost because the damn code review process is such as hassle (most here have resorted to only doing face to face meeting which drives me absolutely bonkers in this day and age and therefore none of my code gets approved). I'm really looking forward to watching this develop and will be glad to pitch in (provided my sales pitch to my group on "why we should use this" works out). Anyway... thought I'd share a) something I've learned, and, b) something I'd suggest given my brief time with 1.9.2-alpha-3 What I learned is that line 62 of lib/Codestriker/Repository/Cvs.pm doesn't seem to export CVS_RSH properly so that it is used by the open/cvs in line 63. If you want to see what I mean: a) change line 63 to use '-t' instead of '-q' to make cvs verbose and try to retieve a diff's full text ("Parallel" view). Look in apache's error_log and you'll see that instead of trying to using ssh, it is instead hung on: Starting server: rsh -l myaccount myhost.mydomain cvs server To understand why, it is using rsh... b) change line 47 of the top codeswitch.conf from '/usr/bin/cvs' to '/tmp/cvs' c) create /tmp/cvs with 755 with the following 2 lines #!/bin/bash echo CVS_RSH is $CVS_RSH d) restart apache (just for grins) Now when you go to retrieve the full text of a diff from CVS via ext: and SSH, instead of hanging, it should show something like the following for line 1: CVS_RSH is So, using ENV there in Cvs.pm isn't getting to the child's environment. My first solution was to just set CVS_RSH before starting apache (e.g. adding the "export" to /etc/sysconfig/httpd on Redhat systems), but that seemed to be overkill. What looked to be a more proper solution was to add the following to httpd.conf: SetEnv CVS_RSH /usr/bin/ssh But, that doesn't seem to be working. (???) That way apache's startup environment isn't polluted, just its children's are (if it worked). So, for now, my workaround is to put: export CVS_RSH /usr/bin/ssh in /etc/sysconfig/httpd unless someone can suggest a better solution as to why either the original code didn't work. I've attached the current nastiness that is my present Cvs.pm's retrieve() function if anyone wants to explore it more. Basically I've come to the conclusion that the environment perl uses for "open()" does not get the complete environment of the perl script it is in UNLESS (for some reason) it was from the environment of the server when it started. So, using "SetEnv CVS_RSH /usr/bin/ssh" in httpd.conf and using "$ENV{'CVS_RSH'}='/usr/bin/ssh';' in the scripts will affect the running environment but not the one the open runs in. Sorry if that's too long and confusing... I'm just trying to clarify my confusion/problems/solutions. I don't know perl for squat... (though it looks kinda like sh and C). If I shouldn't HAVE to set this before starting apache someone please help me out. As for my suggestion... I think the "state of states" needs to be redone. ;) When I see notes like: <quote> # List of valid topic states. Note these values are mapped to the database # depending on their position in the list. ie, Open -> 0, Closed -> 1, etc. # There is no problem added new states dynamically, or changing the textual # names. </quote> I get scared. I'd suggest another database table called "states" (or something) with the following attributes/fields: state_id - short int state_name - short string (char 10 or so) state_desc - long string state_readonly - bool and then loading them up. I think that will be much more robust in the long term since it means we don't have to keep the code aligned with the DB schema and it also kinda nails down the definition of the states. Of course, we'll need a little "state edit" screen like what is available for projects. Anyway... just a thought. I'm also worried about user authentication but for now I think I'm going to try to get away with just using SSL and .htaccess. Finally... my last word of advice for any one new who finds this note in the future... If you are on Linux and your kernel supports/has 'selinux'... turn it off while trying to get it working!!! You can turn it back on later after you've got your repo access working and mail going to all the right places... before then, it will cause you no end of grief. Anyway, great tool... looking forward to seeing it develop. jack j-p...@ta... http://parasol.tamu.edu/people/jkp2866/ p.s. more debug would good... e.g the option to use '-t' instead of '-q' for cvs (without changing code), etc. # Retrieve the data corresponding to $filename and $revision. Store each line # into $content_array_ref. sub retrieve { my ($self, $filename, $revision, $content_array_ref) = @_; # Open a pipe to the CVS repository. print STDERR "from httpd.conf ".$ENV{'CVS_RSH'}."\n"; $ENV{'CVS_RSH'} = $Codestriker::ssh if defined $Codestriker::ssh; print STDERR "from codestriker.conf ".$ENV{'CVS_RSH'}."\n"; open(FOO, '/bin/echo PATH is $PATH - CVS_RSH is $CVS_RSH |') || die "Can't open FOO: $!"; while( <FOO> ) { print STDERR $_."\n"; } close FOO; open(FOO, '/bin/env |') || die "Can't open FOO: $!"; while( <FOO> ) { print STDERR $_; } close FOO; #open(CVS, "\"$Codestriker::cvs\" -q -d \"" . $self->{url} . open(CVS, "\"$Codestriker::cvs\" -t -d \"" . $self->{url} . "\" co -p -r $revision \"$filename\" |") || die "Can't open connection to pserver CVS repository: $!"; # Read the data. for (my $i = 1; <CVS>; $i++) { chop; $$content_array_ref[$i] = $_; } close CVS; } |
From: David S. <si...@us...> - 2006-04-18 07:33:00
|
Hi Jack, > [...] > So, for now, my workaround is to put: > > export CVS_RSH /usr/bin/ssh > > in /etc/sysconfig/httpd unless someone can > suggest a better solution as to why either > the original code didn't work. This sounds to me like you have setup Codestriker with apache2 and mod_perl? Most people I know are using CVS with pserver, or direct access, which is why this isn't an issue reported on very often. If you deploy Codestriker in plain old CGI mode, I suspect the existing code in Cvs.pm which export CVS_RSH will actually work. Under mod_perl however, this probably gets suppressed, particularly under apache2. Can you try with CGI to see if this works? > the perl script it is in UNLESS (for some reason) > it was from the environment of the server when > it started. So, using "SetEnv CVS_RSH /usr/bin/ssh" > in httpd.conf and using "$ENV{'CVS_RSH'}='/usr/bin/ssh';' > in the scripts will affect the running environment > but not the one the open runs in. I think this caveat is right with apache2/mod_perl. Its a damn shame cvs doesn't have a command-line option for specifying what rsh program to use, like rsync, rather than using an environment variable. Cheers, David |
From: Jack P. <j-p...@ta...> - 2006-04-18 15:40:32
|
Howdy David, Thanks. You are correct, sir! $ rpm -q httpd mod_perl httpd-2.0.51-1.10.legacy mod_perl-1.99_12-2 Switching to CGI and tossing the "export CVS_RSH" from the server startup script works as originally advertised/coded (i.e. $ENV{} in Cvs.pm works). It is also remarkably faster in retrieving the full text using CGI than using mod_perl. CGI takes about 3 seconds here to retrieve a 220 line file via SSH. mod_perl takes about 40! Perhaps I should just stick with running in CGI mode for now. I went with mod_perl given the: "Using mod_perl provides performance benefits for Perl-based web applications." blurb in the instructions. In my limited testing, I'm not seeing any "benefits". :) I agree... damn shame that "hysterically" CVS has never provided a command-line option for CVS_RSH (and therefore probably never will). jack j-p...@ta... On Tue, 2006-04-18 at 02:35, David Sitsky wrote: > Hi Jack, > > > [...] > > So, for now, my workaround is to put: > > > > export CVS_RSH /usr/bin/ssh > > > > in /etc/sysconfig/httpd unless someone can > > suggest a better solution as to why either > > the original code didn't work. > > This sounds to me like you have setup Codestriker with apache2 and > mod_perl? Most people I know are using CVS with pserver, or direct > access, which is why this isn't an issue reported on very often. > > If you deploy Codestriker in plain old CGI mode, I suspect the existing > code in Cvs.pm which export CVS_RSH will actually work. Under mod_perl > however, this probably gets suppressed, particularly under apache2. > > Can you try with CGI to see if this works? > > > the perl script it is in UNLESS (for some reason) > > it was from the environment of the server when > > it started. So, using "SetEnv CVS_RSH /usr/bin/ssh" > > in httpd.conf and using "$ENV{'CVS_RSH'}='/usr/bin/ssh';' > > in the scripts will affect the running environment > > but not the one the open runs in. > > I think this caveat is right with apache2/mod_perl. Its a damn shame > cvs doesn't have a command-line option for specifying what rsh program > to use, like rsync, rather than using an environment variable. > > Cheers, > David > |
From: Jack P. <j-p...@ta...> - 2006-04-18 15:57:32
|
Sorry... wrong system/versions... FWIW/FYI it actually was: $ rpm -q httpd mod_perl httpd-2.0.52-22.ent.centos4 mod_perl-1.99_16-4.centos4 [not that it matters] jack (who wasn't paying attention to what box he was on at the time) On Tue, 2006-04-18 at 10:40, Jack Perdue wrote: > Howdy David, > > Thanks. You are correct, sir! > > $ rpm -q httpd mod_perl > httpd-2.0.51-1.10.legacy > mod_perl-1.99_12-2 > > Switching to CGI and tossing the "export CVS_RSH" > from the server startup script works as originally > advertised/coded (i.e. $ENV{} in Cvs.pm works). > > It is also remarkably faster in retrieving the full text > using CGI than using mod_perl. CGI takes about 3 seconds > here to retrieve a 220 line file via SSH. mod_perl takes > about 40! > > Perhaps I should just stick with running in CGI mode for now. > I went with mod_perl given the: > > "Using mod_perl provides performance benefits for Perl-based > web applications." > > blurb in the instructions. In my limited testing, > I'm not seeing any "benefits". :) > > I agree... damn shame that "hysterically" CVS has never provided > a command-line option for CVS_RSH (and therefore probably never will). > > jack > j-p...@ta... > > > On Tue, 2006-04-18 at 02:35, David Sitsky wrote: > > Hi Jack, > > > > > [...] > > > So, for now, my workaround is to put: > > > > > > export CVS_RSH /usr/bin/ssh > > > > > > in /etc/sysconfig/httpd unless someone can > > > suggest a better solution as to why either > > > the original code didn't work. > > > > This sounds to me like you have setup Codestriker with apache2 and > > mod_perl? Most people I know are using CVS with pserver, or direct > > access, which is why this isn't an issue reported on very often. > > > > If you deploy Codestriker in plain old CGI mode, I suspect the existing > > code in Cvs.pm which export CVS_RSH will actually work. Under mod_perl > > however, this probably gets suppressed, particularly under apache2. > > > > Can you try with CGI to see if this works? > > > > > the perl script it is in UNLESS (for some reason) > > > it was from the environment of the server when > > > it started. So, using "SetEnv CVS_RSH /usr/bin/ssh" > > > in httpd.conf and using "$ENV{'CVS_RSH'}='/usr/bin/ssh';' > > > in the scripts will affect the running environment > > > but not the one the open runs in. > > > > I think this caveat is right with apache2/mod_perl. Its a damn shame > > cvs doesn't have a command-line option for specifying what rsh program > > to use, like rsync, rather than using an environment variable. > > > > Cheers, > > David > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Codestriker-user mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codestriker-user |
From: David S. <si...@us...> - 2006-04-18 23:31:29
|
> It is also remarkably faster in retrieving the full text > using CGI than using mod_perl. CGI takes about 3 seconds > here to retrieve a 220 line file via SSH. mod_perl takes > about 40! That is very strange indeed to see such a time difference... that is certaintly not my experience. I keep finding strange things occurring with mod_perl, particularly when launching external programs, and how stdout/err is handled. When in doubt - stick with CGI. Cheers, David |
From: Jason R. <jre...@ya...> - 2006-04-19 03:07:36
|
Hi, Also, for the record, you need a different Apache config directive to set an environment variable in mod_perl http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlSetEnv_ That is why SetEnv did not work. Thanks Jason --- Jack Perdue <j-p...@ta...> wrote: > Howdy David, > > Thanks. You are correct, sir! > > $ rpm -q httpd mod_perl > httpd-2.0.51-1.10.legacy > mod_perl-1.99_12-2 > > Switching to CGI and tossing the "export CVS_RSH" > from the server startup script works as originally > advertised/coded (i.e. $ENV{} in Cvs.pm works). > > It is also remarkably faster in retrieving the full text > using CGI than using mod_perl. CGI takes about 3 seconds > here to retrieve a 220 line file via SSH. mod_perl takes > about 40! > > Perhaps I should just stick with running in CGI mode for now. > I went with mod_perl given the: > > "Using mod_perl provides performance benefits for Perl-based > web applications." > > blurb in the instructions. In my limited testing, > I'm not seeing any "benefits". :) > > I agree... damn shame that "hysterically" CVS has never provided > a command-line option for CVS_RSH (and therefore probably never will). > > jack > j-p...@ta... > > > On Tue, 2006-04-18 at 02:35, David Sitsky wrote: > > Hi Jack, > > > > > [...] > > > So, for now, my workaround is to put: > > > > > > export CVS_RSH /usr/bin/ssh > > > > > > in /etc/sysconfig/httpd unless someone can > > > suggest a better solution as to why either > > > the original code didn't work. > > > > This sounds to me like you have setup Codestriker with apache2 and > > mod_perl? Most people I know are using CVS with pserver, or direct > > access, which is why this isn't an issue reported on very often. > > > > If you deploy Codestriker in plain old CGI mode, I suspect the existing > > code in Cvs.pm which export CVS_RSH will actually work. Under mod_perl > > however, this probably gets suppressed, particularly under apache2. > > > > Can you try with CGI to see if this works? > > > > > the perl script it is in UNLESS (for some reason) > > > it was from the environment of the server when > > > it started. So, using "SetEnv CVS_RSH /usr/bin/ssh" > > > in httpd.conf and using "$ENV{'CVS_RSH'}='/usr/bin/ssh';' > > > in the scripts will affect the running environment > > > but not the one the open runs in. > > > > I think this caveat is right with apache2/mod_perl. Its a damn shame > > cvs doesn't have a command-line option for specifying what rsh program > > to use, like rsync, rather than using an environment variable. > > > > Cheers, > > David > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Codestriker-user mailing list > Cod...@li... > https://lists.sourceforge.net/lists/listinfo/codestriker-user > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: David S. <si...@us...> - 2006-04-18 07:37:13
|
Hi Jack, > [...] > I'd suggest another database table called "states" (or something) > with the following attributes/fields: > > state_id - short int > state_name - short string (char 10 or so) > state_desc - long string > state_readonly - bool > > and then loading them up. I think that will be > much more robust in the long term since it means > we don't have to keep the code aligned with the DB > schema and it also kinda nails down the definition > of the states. > > Of course, we'll need a little "state edit" screen > like what is available for projects. > > Anyway... just a thought. Sounds good to me. The reason why it is the way it is is because of "hysterical" reasons - the days before Codestriker even used a database for persistence. Having said that, there is no reason why we couldn't migrate to the above schema. I'm pretty busy these days, so I don't know when I'd work on this. I've added it to the task list though so it is not forgotten. Cheers, David |