Wanted: Modperl/Mason consultant:
Hello. We have an Apache/Modperl/Mason/Oracle system and no programmers experienced with the front end environment. (details available on request). We are the Oracle programmer/DBA and Unix admin guys and fumble around in the Perl as needed. Slowly coming up to speed on Perl. The Apche server is Solaris Intel, the Oracle database (7.3.4) may be on Solaris or Windows NT. Our conclusion is that we need some adult supervision to get over some of the rough spots as we develop proficiency in this tool set. We are further handicapped by the reality that we each only have a few hours a week to devote to the Web side of our application. I don't even have time to stay current with the modperl mailing list. The types of problems you would help us with include. -- On a new Apache server we were bringing up, our program would not write a file. It took us two days to decide to look at the permissions on the directory in question and give everybody write privilege. You would have asked the question very early on. -- Whilst working on a tedious but routine fix, in a moment of paranoia I managed to convince myself that changes to the /usr/local/lib/perl tree were not getting picked up by Apache unless I rebooted the host machine. You would have calmed me down and suggested that I look deeper into my database logic. -- We have a nasty problem where sessions seem to refuse to die unless the client browser exits. Still don't know where the problem is. -- You will take us to the magical world of modperl debugging. It will be like Disney World, only better. I'm sure of it. Requirements -- Very proficient with Modperl and Mason. Experience with CGI a plus. -- Focus. The abrupt departure of the Web team left a lot of "gotta do's" in the application system. You'll need to overlook those and focus on the problem at hand. -- We would probably need less than 5 hours a week of your time. We have flexible hours. -- Sense of humor: we'll be pretty punchy by the time we need your services. -- You will have to execute a non-disclosure/non-compete agreement drawn up by our ubiquitous legal staff. If this is of interest to you, please forward a resume and rate to me at [EMAIL PROTECTED] Thanks robert monical [EMAIL PROTECTED] "Letter writing is the only device for combining solitude and good company." Lord Byron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Privilege Management
We are writing a specification for an Apache/modperl based data entry/update system that will operate against an Oracle database. I am a Perl/modperl novice. This will be a lightly loaded Web Server (less then a dozen concurrent "sessions", 100s of updates/hour). Users will log in. I assume that we will use Apache Session and URL rewriting to manage user sessions. Users will have a profile defining which actions are allowable. Since there are so many cool Perl tools out there, I would like a sanity check on our proposed Privilege Management approach. The number of privileges will start at less than 20 and will certainly never grow to more than 50. - We will have a user table We will have a table for actions that lists each possible action. We will have a join table linking users to allowable actions. Each screen has a defined list of possible actions. This information is "hardcoded" into the entry logic for the screen. When a screen is sent to the user, the possible action is checked and enabled/disabled based on the user privilege. The maintenance screen for these tables will be in Oracle forms. Is there a better way? Thanks! p.s. What I would love to see is the ability for each display object that links to an action to set it's own enabled/disabled state. Not sure how this might be accomplished in a Web environment. --Robert Monical --Director of CRM Development [EMAIL PROTECTED]
Re: Modperl/Apache deficiencies... Memory usage.
I am not very knowledgeable but have been lurking on this list for a couple of months. The last week (or two) have seen a number of posts about having two Apaches. A light weight front end and a mod-perl enabled back end. Since I do not fully understand what folks are talking about, these all go in an archive for me to read later. In the application that I inherited, a front ends feeds into a modperl engine for the database portion of the session. All static downloads go to another instance, in our case, on separate hardware. What are your thoughts about that approach as opposed to your idea? At 12:03 AM 4/15/00, [EMAIL PROTECTED] wrote: >Modperlers..., > >I'd like to start a discussion about the deficiences in Apache/modperl >and get you feedback with regard to this issue. The problem as I see >it is that the process model that Apache uses is very hard on modperl. >It is very memory inneffecient basically. Each process of apache has >it's registry which holds the compiled perl scripts in..., a copy of >each for each process. This has become an issue for one of the >companies that I work for, and I noted from monitoring the list that >some people have apache processes that are upwards of 25Megs, which is >frankly ridiculous. > >This is not meant to be a flame, and I'd really like to get down to >the nitty gritty on how we can solve this problem. Zach Brown wrote >phhttpd which is a threaded server which can handle a lot more load >than apache, but the problem is it doesn't have the features that >Apache has, and it's not going to catch up any time soon so I think >it's not going to be the cure-all. I wrote a very small perl engine >for phhttpd that worked within it's threaded paradigm that sucked up a >neglibible amount of memory which used a very basic version of >Apache's registry. Once again though it didn't have the feature set >that Apache/modperl has. Now to address the issue: I think we have a lot of >code in Modperl that is basically awesome. Not to mention the fact >that Apache itself has a lot of modules and other things which are >quite usefull. However I think if it were possible to divorce the >actually perl engine from the Apache process we could solve this memory >usage problem. > >Basically heres what I'm thinking might be possible, but if it's not >just let me know. (Well, I know it's possible, but I mean how much >work would it take to institute, and has someone else worked on this, >or taken a look at how much work we'd be talking about) What I'm >thinking is essentially we take the perl engine which has the apache >registry and all the perl symbols etc., and seperate it into it's own >process which would could be multithreaded (via pthreads) for multiple >processor boxes. (above 2 this would be beneficial probably) On the >front side the apache module API would just connect into this other >process via shared memory pages (shmget et. al), or Unix pipes or >something like that. The mod_perl process would have a work queue >that the Apache processes could add work to via our front end API. >The work threads inside of that mod_perl process would take work >"orders" out of the work queue and process them and send the result >back to the waiting apache process. (Maybe just something as simple >as a blocking read on a pipe coming out of the mod_perl process... >this would keep down context switching issues and other nasty bits) > >One of my concerns is that maybe the apache module API is simply too >complex to pull something like this off. I don't know, but it seems >like it should be able to handle something like this. > >Does anyone know of any program which has been developed like this? >Basically we'd be turning the "module of apache" portion of mod_perl >into a front end to the "application server" portion of mod_perl that >would do the actual processing. It seems quite logical that something >like this would have been developed, but possibly not. The seperation >of the two components seems like it should be done, but there must be >a reason why no one has done it yet... I'm afraid this reason would be >the apache module API doesn't lend itself to this. > >Well, thanks to everyone in advance for their thoughts/comments... >Shane Nay. Have a great day! --Robert Monical --Director of CRM Development [EMAIL PROTECTED] "The Truth is Out There"
Re: PLEASE HELP!!!!! I cannot get mod_perl/apache compiled
Shared pain! Have just been through this. Sequencing is a little arcane. Make mod_perl Install mod_perl Make Apache Install Apche Make test mod_perl. Mod_perl needs a perl aware Apache. The additions to the http.conf are stripped out by a perl aware Apache. I may not have addressed your specific issue, since I have not seen the first error message. At 09:20 PM 4/12/00, Sam Carleton wrote: >I simply cannot get mod_perl/apache to compile. My understanding is >that I configure .makepl_args.mod_perl to compile both mod_perl. Then I >do the following: > >perl Makefile.PL >make >make test >make install > >Assuming there where no problems, all should be installed and ready to >go. But all is not well. First some version info. I just downloaded >mod_perl-1.22 and apache_1.3.12 and am working with fresh trees. I run >the perl Makefile.PL and that seems to work well, I don't see any >errors. When I try to run make, I get this error: > ># make >(cd /usr/src/apache_1.3.12 && make) >make[1]: Entering directory `/usr/src/apache_1.3.12' >make[1]: *** No targets. Stop. >make[1]: Leaving directory `/usr/src/apache_1.3.12' >make: *** [apaci_httpd] Error 2 > >My understanding is that the `perl Makefile.PL` WILL also run configure >for apache. Just to make sure I was not mistaken, I have tried to first >go into the apache tree and run configure with the same options that are >in my .makepl_args.mod_perl. Then run `perl Makefile.PL`, run `make` >(which works this time), and then run `make test`. It is `make test` >that bombs out with this error: > >letting apache warm up...\c >Syntax error on line 30 of /usr/src/mod_perl-1.22/t/conf/httpd.conf: >Invalid command '=pod', perhaps mis-spelled or defined by a module not >included in the server configuration >done >/usr/local/bin/perl t/TEST 0 >still waiting for server to warm up...not ok >server failed to start! (please examine t/logs/error_log) at t/TEST line >95. >make: *** [run_tests] Error 111 > > >Now, there is no 't/logs/error_log' file to examine. But I did notice >an error in reading in the the httpd.conf file. I looked into line 30 >of '/usr/src/mod_perl-1.22/t/conf/httpd.conf' and this is what I found: > >=pod > >=head1 NAME > >mod_perl test configuration file > >=head1 DESCRIPTION > >umm, we use this to test mod_perl > >=over to apache > > >I am under the impression that the httpd.conf file is the conf file that >httpd is reading in for the test. My understanding is that equals is >not a valid beginning of an apache conf file. > >I have NO CLUE as to what is going on here. I would truly appreciate it >if you know anything about this please let me know what is going on. At >the bottom you will find my '.makepl_args.mod_perl' and the command line >options I am using for apache. > >Sam > >--.makepl_args.mod_perl-- ># File: .makepl_args.mod_erl ># enable all phase callbacks, API modules and misc features >EVERYTHING=1 > ># tell runtime diagnostics to active if MOD_PERL_TRACE environment ># variable is set at runtime >PERL_TRACE=1 > ># tell Makefile.pl where the Apache source tree is >APACHE_SRC=/usr/src/apache_1.3.12/src > ># tell Makefile.PL where the Apache is to be isntalled >APACHE_PREFIX=/data01/apache > ># disable Makefile.pl from compiling Apache >#PREP_HTTPD=1 > ># tell Makefile.PL to use the first source found, which will be the ># path specified above by APACHE_SRC >DO_HTTPD=1 > ># tell Makefile.PL to configure Apache using the apaci interface >USE_APACI=1 > ># tell makefile.PL to configure ssl support, too >#-SSL_BASE=/usr/local/ssl > ># add mod_info, mod_status, mod_usertrack, and mod_unique_id >#-ADD_MODULE=info,status,usertrack,unique_id > ># additional arguments to give Apache's configure script ># aruments can be delimited by comma and/or specified with multipal ># APACI_ARGS lines >#APACI_ARGS=--includedir=/usr/src/php >#APACI_ARGS=--activate-module=src/modules/php3/libphp3.a >APACI_ARGS=--with-layout=apache.config.layout:Sam-Layout >APACI_ARGS=--server-uid=wwwrun >APACI_ARGS=--server-gid=dosemu >APACI_ARGS=--enable-module=most >APACI_ARGS=--enable-shared=max >--.makepl_args.mod_perl-- > > > >--apache config script---------- >#! /bin/sh >ROOT_DIR=/usr/src > >$ROOT_DIR/apache_1.3.12/configure \ > --with-layout=/root/apache.config.layout:Sam-Layout \ > --with-perl=src/modules/perl \ > --enable-module=most \ > --server-uid=wwwrun \ > --server-gid==dosemu \ > --enable-shared=max >--apache config script-- Have a great day! --Robert Monical --Director of CRM Development [EMAIL PROTECTED] "The Truth is Out There"
Re: [OT slightly] mod_perl developers (do they exist in Buffalo NY?)
Hello, Looking for a mod_perl developer in Buffalo. The site is <http://www.destinations.com/>www.destinations.com. The booking engine bit is mod_perl. Several new products are in the pipeline. Please respond to [EMAIL PROTECTED] Thanks Have a great day! --Robert Monical --Director of CRM Development [EMAIL PROTECTED] --Work: 206-855-8222 "The Truth is Out There"
