My OS X Adventures
Hi All, Thanks to the hard work of those who have gone before me, I've managed to get all the Perl-oriented tools I need working under Mac OS X. I was spending a lot of effort on documenting what I needed to do, so I went the extra mile and wrote up an article on what I did and how I did it. And now I share it with you. Feedback is welcome! http://david.wheeler.net/osx.html Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: mod_perl stopped working...
At 11:55 AM -0700 4/11/2002, Alex S wrote: > >My real point is not a matter of technical savviness. It's more that >something Apple pushed out broke something I, and others have setup. I >might even have been more cautious about the update IF they listed it as >something being updated, which they did NOT do. Alex, http://docs.info.apple.com/article.html?artnum=120111 lists only the security-related components in the update. If you are concerned about the complete contents of an update (and I would suggest that in any case where you are in the habit of replacing apple-supplied binaries you do), I recommend that you examine an exhaustive manifest before performing the install. If you can't find a site that publishes a manifest, then learn how to extract one for yourself using lsbom(8) or pax(1) or using a tool like pacifist. In this case, Apple listed mod_ssl 2.8.7 (technically 2.8.7-1.3.23 as mod_ssl is always paired with specific apache versions) as the updated version. This implies that Apache would be updated to 1.3.23. From that, it stands to reason that a number - if not most - of the Apple-delivered DSOs would be recompiled as well and included in the install. A good low-noise site for keeping track of these sort of updates and their implications is Stepwise. Their announcement on the update http://www.stepwise.com/Articles/News/2002-04-05.01.html includes Apache-specific information. They don't provide perl & mod_perl instructions on Stepwise, but if Apple changes something with Apache, they'll flag it and you can notice it there. As others have noted, there is nothing new under the sun. These issues are common to all *nix packaging systems. Those who don't want Apple to break what they've installed should either install things in other locations (fink does this, from what I understand) or leave the Apple- installed packages alone. It's a good lesson to learn. It's unfortunate that it's more frequently learned firsthand than through secondhand annectodal accounts. -Charles [EMAIL PROTECTED]
Re: more security update woes
On 4/11/02 9:46 AM, "Rick Frankel" <[EMAIL PROTECTED]> claimed: > Tangential to the mod_perl issue, has anyone else noticed that > ~/.MacOSX/environment.plist is no longer being parsed on login after > the security update? Seems to be working for me. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: mod_perl stopped working...
PK, here, stands to represent the opposite of myself... he represents the "bulk" that I was referring to that would have the knowledge to do a very simple CPAN install/update, and even cut'n'pasting commands for a manual recompile (which are easy to find with a quick google search), but wouldn't have a clue about what happens during the C compilation and dynamic libraries. My real point is not a matter of technical savviness. It's more that something Apple pushed out broke something I, and others have setup. I might even have been more cautious about the update IF they listed it as something being updated, which they did NOT do. Especially in the situation where they are not disclosing every detail, they could put a little more effort in support of the things they are encouraging and marketting. Perl is one thing that is appealing. They ARE drawing newbies into a new world. And no matter who's fault it really comes down to, it's the customers who will blame the update. Cause, effect. Just look at the remarks on VersionTracker. Most complaints are due to something the individual did, but Apple will take the brunt of accusation. Anyway... I'm happy now... I hope your stuff works out PK. -Alex PK Eidesis wrote: > > >I second Alex's feelings about this... keep in mind, I speak as a total Perl >newbie, not necessarily a computer newbie. Even though I know my way around >cron and grep, I am not really proficient at *nix or Perl, but I appreciate >both. MacOS X is truly wonderful since it brings the coherence, ease, and >beauty of MacOS with the diversity and cultural chaos of *nix and Perl. But >my MacOS background stands in mixed awe of something like > >s//pop/e;print^s/./hex($`%10+$&)%15/eg&&do$0 > >I say "mixed awe" because it is awesome, but it is also obtuse. Until my >fingers can create something like that in unison with my brain, I am an >outsider. > >I really want to use Perl and learn it, but I want to spend more time using >and learning it, and less time trying to figure out why it is not working. I >loved reading through the llama book because Randal held my hand, made me >grin, and shake my head in amusement and wonder. > >But this whole Perl 5.6.1, mod_perl crapola has left me very befuddled. In >some ways I have myself to blame because I dicked with Apple's stock 5.6.0 >install... I never should have done that. Otoh, Perl/CPAN/mod_perl install >should have protected me from screwing myself up. > >Perl started as a system mgt. language (more or less), as a text processing >language. It has now morphed into countless other uses. One use that >intersects my interests is as a web server, database, middleware glue. To >that extent, I really would like an Apache/mod_perl/DBI/Perl bundle in all >its double-clickable goodness. > >Of course, wanting something doesn't make it happen. I would make it myself >if I were Perl savvy enough to begin with. But therein lies the catch-22. I >want something I am not good enough to make myself. > >This list is cool because it shows there is great interest in Perl among >MacOS X users. I have seen some famous Perl names on this list (you know who >you are). Hopefully, we will all benefit from their insight and help. >
Re: mod_perl stopped working...
On 4/11/02 1:31 PM, "PK Eidesis" <[EMAIL PROTECTED]> wrote: > > But this whole Perl 5.6.1, mod_perl crapola has left me very befuddled. In > some ways I have myself to blame because I dicked with Apple's stock 5.6.0 > install... I never should have done that. Otoh, Perl/CPAN/mod_perl install > should have protected me from screwing myself up. > FWIW, the CPAN behavior that tries to get you to upgrade to 5.6.1 is actually a bug in CPAN, that can be avoided if you upgrade to the latest CPAN *by hand* (not using CPAN). The problem is with installing modules that have been merged into the base perl install - it doesn't understand that it can get them on their own, so it gets them by grabbing the latest perl. This has caused a lot of problems for us when installing modules. Ian
Re: mod_perl stopped working...
On Thursday, April 11, 2002, at 01:28 PM, Alex S wrote: > Well, since Apple is the one pushing out the update to Apache (and > related modules), they know what they're changing (including libraries). It's true that Apple knows what *they're* changing, but the problem is that they have no way of knowing what *you and I* may have changed. That's a completely different kettle of fish. > I'm just saying that it's a poor assumption for a business to make, > that their customers (especially the bulk of Mac users) will understand > the importance of relinking with library updates. That's not the assumption they're making. The vast majority of Apple's customers didn't have this problem, because they hadn't updated Perl to begin with. The assumption that Apple is making is that the tiny handful of customers who are tech-savvy enough to update Perl, will also be tech-savvy enough to deal with the problems caused by doing so. You've helped validate that assumption yourself, by doing just that. :-) Linux distributions have similar issues, btw - it's not exclusive to OS/X. If you use (for example) Red Hat, and you update a library by compiling the new version from source, binary RPMs that were configured and compiled against the Red Hat supplied version of that library will most likely not work. The same is true for binary packages under Solaris, and any other *NIX of which I am aware. As a rule of thumb, updating things by hand will always, sooner or later, cause problems with package managers, because the people creating and testing the packages can only test them against a finite number of configurations. sherm-- Never put off until tomorrow what you can do today. There might be a law against it by that time.
Re: mod_perl stopped working...
Oh... and despite the "shoulds" and "shouldn'ts"... I hope this thread will help enlighten and educate those who need to know, and solve their problems. That's why I summarized my solution about the linking of libraries in the first place. It's often VERY annoying when I have a problem, and search for answers only to find people asking about the problem, and rarely the solution being posted. :) Cheers, -Alex
Re: mod_perl stopped working...
Sherm Pendley wrote: > No need to wonder about what it's doing - just watch the output when > you configure and make Perl, and then you'll know for certain. > > The answer to your question is, no, the Perl compile/installation does > not do any relinking for things that were linked against libperl. The > reason for this is simple and obvious: Perl's configuration script has > no way of knowing what those "things" are, or where to find the source > code with which to recompile them. The same applies to Apple's updater. That's what I would have thought, but the fact that the original recompile to 5.6.1 that did not break mod_perl made me "wonder". I was thinking, contrary to my instincts, that there might be some mechanism that keeps track of links (in reverse). Just a pure theory with little foundation as a logical path to prove or disprove. :) > Unless you know *precisely* what's going on - that is, what exported > symbols have changed between one library version and the next, and > what symbols are required by each application that uses that library - > you should always assume that changing a library will disturb > applications that require it. Yeah, that's the thinking I wish Apple would take when they push out a library update! :) >> Apparently this wasn't the case here. Since Apple has taken it upon >> themselves to hide the update process (definitely a good thing for >> ease of use), it seems they should also think about what happens when >> libraries are updated and handle it. > > > Handle it how? How is Apple supposed to know which of an infinite > number of library/module combinations you've installed? It's > impossible. They test their updates against a fixed number of known, > supported system configurations - anything else is terra incognito. Well, since Apple is the one pushing out the update to Apache (and related modules), they know what they're changing (including libraries). Although I have not verified this, I'm enclined to think that this update was solely a binary push, and not a compiled update. If it were the latter (which some (few) Software updates are), then the relinking would have occured and PK and I wouldn't be having this problem (and likely others). > Apple's policy on this is clear, and perfectly reasonable: The /System > folder belongs to Apple. The computer belongs to you, of course, and > you're free to change anything you like, but if you make changes under > /System, you're on your own. Yeah... true... however tell that to CPAN, which THEY installed! If I do a CPAN install on a module, it puts things under /System. Yeah, I know this, you know this, and now everyone on this list knows this... but a process that is generally considered safe, standard, and common (Perl module installations via CPAN) will do things a less tech savy person will not be aware of. And don't use the argument "they should be more tech savy"... because this isn't a eutopia, and Apple has to deal with their customers despite what "they should know". What they DO know, is that most Perl sites preach doing CPAN module installations left and right, and many of them will require an update to Perl. My problem is resolved it was only a minor headache. But to the bulk of Apple's customer, who are not as "*nix" oriented, it may be a bigger headache. And many of them are being told about the wonders of what OS X can offer (read: CPAN, perl, etc). This is not meant to be a flame... like I said, my problem is resolved, and I understand the problem and solution, and will be sure to remember to not trust what Apple says is being updated and dig into the update file myself... I'm just saying that it's a poor assumption for a business to make, that their customers (especially the bulk of Mac users) will understand the importance of relinking with library updates. Thanks for the input... I'm just glad I can tinker with mod_perl again on my PowerBook. Cheers, -Alex
Re: mod_perl stopped working...
On Thursday, April 11, 2002, at 12:42 PM, Alex S wrote: > I wonder if the Perl compile/installation does the relinking for > things that were dependent on it (would be a good thing, making things > simple, and catching everything). No need to wonder about what it's doing - just watch the output when you configure and make Perl, and then you'll know for certain. The answer to your question is, no, the Perl compile/installation does not do any relinking for things that were linked against libperl. The reason for this is simple and obvious: Perl's configuration script has no way of knowing what those "things" are, or where to find the source code with which to recompile them. The same applies to Apple's updater. >> any time you make a system change like that it can disturb linkages, >> and >> that's exactly what you're seeing here... > > Can, but doesn't always. Unless you know *precisely* what's going on - that is, what exported symbols have changed between one library version and the next, and what symbols are required by each application that uses that library - you should always assume that changing a library will disturb applications that require it. > Apparently this wasn't the case here. Since Apple has taken it upon > themselves to hide the update process (definitely a good thing for ease > of use), it seems they should also think about what happens when > libraries are updated and handle it. Handle it how? How is Apple supposed to know which of an infinite number of library/module combinations you've installed? It's impossible. They test their updates against a fixed number of known, supported system configurations - anything else is terra incognito. Apple's policy on this is clear, and perfectly reasonable: The /System folder belongs to Apple. The computer belongs to you, of course, and you're free to change anything you like, but if you make changes under /System, you're on your own. sherm-- Never put off until tomorrow what you can do today. There might be a law against it by that time.
more security update woes
Tangential to the mod_perl issue, has anyone else noticed that ~/.MacOSX/environment.plist is no longer being parsed on login after the security update? rick
Re: mod_perl stopped working...
Chris Devers wrote: >>>But isn't it supposed to not work unless it offers error messages? >>> >>You would think so >> > >I was having fun with the [snipped] double negative earlier... :) > Yeah, I kinda figured... just covering the bases. ;) >>Well, the thing is, I don't think it even gets that far in executing the >>conf file. >> > >You think? Or you know? What does "apachectl configtest" tell you? > Well, the syntax checking will fail if you don't have the LoadModule. However, if the LoadModule line is present, that will pass, the conf will load, compile, and execute... However, it didn't make it to the point past the LoadModule line. The invalid linking of libraries to the updated Perl probably made the whole process up and die. The most disturbing thing though is that there's absolutely no error messages. Only the normal startup log entries, ending just before the ones that would normally appear for the loading of mod_perl. >As mentioned later in this thread, the problem is very likely to be that >Perl and mod_perl are out of sync, and that they'll only work is built >against the same version. If you upgrade Perl, you need to do the same for >mod_perl. Downgrading back to 5.6.0 brought them back into sync. > Yeah I was the one that originally mentioned it. :) The problem of linking occured to me when I started to think more thoroughly what occurs with Apple's updates. So, I decided to test that theory. I'm sure upgrading back to 5.6.1 would work again. Oddly, I didn't need to recompile mod_perl when I first updated Perl and things were fine. I wonder if the Perl compile/installation does the relinking for things that were dependent on it (would be a good thing, making things simple, and catching everything). >Again, I think this is a general mod_perl issue, and not OSX related -- >any time you make a system change like that it can disturb linkages, and >that's exactly what you're seeing here... > Can, but doesn't always. In other updates from Apple where linking mismatches are more clear, the update relinked the libraries. Apparently this wasn't the case here. Since Apple has taken it upon themselves to hide the update process (definitely a good thing for ease of use), it seems they should also think about what happens when libraries are updated and handle it. Yes, I know that I can manually pick apart the update, if I manually downloaded it (did that), but it shouldn't be necessary. It can't be THAT uncommon that people do CPAN module installs, which can often result in an automatic update of Perl. In light of that, I would hope that Apple would take into consideration that possibility with future updates. Cheers, -Alex >
Re: mod_perl stopped working...
Sherm Pendley wrote: >> wondering if the mod_perl library was reinstalled with the new Apache >> (probably), which had some dynamic linking done, designed for perl 5.6.0 >> (or possibly vice-versa), and the updated copy got "out of sync" with >> the >> newer perl. > > > Of course it got out of synch - Apple's mod_perl is compiled against > Perl 5.6.0, but you've installed Perl 5.6.1. > > If you update Perl, you must update mod_perl as well. And, in both > cases, if you've installed them in the same location as the > Apple-installed versions, you'll inevitably run into trouble when (not > if) some future update from Apple overwrites your customized install. Although I agree with you in concept. This was not an issue when upgrading from 5.6.1. I did not have to reinstall mod_perl at that time, and things worked fine. It was only when mod_perl was updated with the Apache update (latest Security update). I'm guessing that the update to 5.6.1 scanned and relinked the libraries. I would have hoped that Apple's updates would check to see if relinking is necessary. They do this for larger updates (such as Developer tools), where it's clear this is needed. This really does seem like an oversight in the Security Update, making the assumption that no one updated Perl. Apple could have really simplified things for their users if they checked for necessary relinking of the libraries when updating them. > This isn't an OS/X issue - you'll get the same results any time the > installed version of Perl is different from the one against which > mod_perl is linked, regardless of OS. True. Although it is specific to Apple's Update procedure that caused this problem. Especially since Apache isn't even listed as one of the things being updated in the update docuementation. Cheers, -Alex
Re: mod_perl stopped working...
On Thu, 11 Apr 2002, BeardedDragon.org wrote: > On Thu, 11 Apr 2002 10:05:46 -0400 (EDT), Chris Devers wrote: > > > But isn't it supposed to not work unless it offers error messages? > > You would think so I was having fun with the [snipped] double negative earlier... :) > > It's only a partial remedy, but are your mod_perl related config statments > > wrapped in an appropriate block? > > > > > > PerlSendHeader On > > PerlHandler Apache::Registry > > AddHandler perl-script .mpl > > > > Well, the thing is, I don't think it even gets that far in executing the > conf file. You think? Or you know? What does "apachectl configtest" tell you? > In my case, I'm suspecting that something in the current > mod_perl installation was conflicting with the perl 5.6.1. As mentioned later in this thread, the problem is very likely to be that Perl and mod_perl are out of sync, and that they'll only work is built against the same version. If you upgrade Perl, you need to do the same for mod_perl. Downgrading back to 5.6.0 brought them back into sync. Again, I think this is a general mod_perl issue, and not OSX related -- any time you make a system change like that it can disturb linkages, and that's exactly what you're seeing here... -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ "More war soon. You know how it is."-- mnftiu.cc
Re: mod_perl stopped working...
On Thursday, April 11, 2002, at 11:32 AM, BeardedDragon.org wrote: > wondering if the mod_perl library was reinstalled with the new Apache > (probably), which had some dynamic linking done, designed for perl 5.6.0 > (or possibly vice-versa), and the updated copy got "out of sync" with > the > newer perl. Of course it got out of synch - Apple's mod_perl is compiled against Perl 5.6.0, but you've installed Perl 5.6.1. If you update Perl, you must update mod_perl as well. And, in both cases, if you've installed them in the same location as the Apple-installed versions, you'll inevitably run into trouble when (not if) some future update from Apple overwrites your customized install. This isn't an OS/X issue - you'll get the same results any time the installed version of Perl is different from the one against which mod_perl is linked, regardless of OS. sherm-- Never put off until tomorrow what you can do today. There might be a law against it by that time.
Re: mod_perl stopped working...
On Thursday, April 11, 2002, at 09:51 AM, Sherm Pendley wrote: > On Thursday, April 11, 2002, at 10:34 AM, Puneet Kishor wrote: > >> I have started experiencing these problems on my iBook ever since I >> upgraded Perl to 5.6.1. > > When you did that, did you also recompile mod_perl, or at least install > a version of mod_perl that's compiled against Perl 5.6.1? If you don't, > Bad Things will happen - regardless of what OS you're using. > After installing 5.6.1, I used CPAN to install mod_perl. I am assuming CPAN did the right thing for me, no? pk/
Re: mod_perl stopped working...
On Thursday, April 11, 2002, at 10:34 AM, Puneet Kishor wrote: > I have started experiencing these problems on my iBook ever since I > upgraded Perl to 5.6.1. When you did that, did you also recompile mod_perl, or at least install a version of mod_perl that's compiled against Perl 5.6.1? If you don't, Bad Things will happen - regardless of what OS you're using. sherm-- Never put off until tomorrow what you can do today. There might be a law against it by that time.
Re: mod_perl stopped working...
On Thu, 11 Apr 2002 09:34:09 -0500, Puneet Kishor wrote: > if it is a general mod_perl issue then it should be happening to, and be > well documented for, a lot of other users. I have done some bg search on > this, and not found anyone else experiencing the same symptoms. That is, > until Alex wrote in his email. Yeah...same here. And I agree, I don't think this is common. As it seems to be consistent with perl 5.6.1 on Mac OS X, with the security update screwing with things. I've seen mod_perl working with the same level of Apache and Perl on a Linux box. > I have started experiencing these problems on my iBook ever since I > upgraded Perl to 5.6.1. On my Powerbook, where Perl is still at 5.6.0, > there is no such problem at all. In reverse here (sorta). My PowerMac has 5.6.0 and no problems. PowerBook has 5.6.1, which is where it's not working. > I don't know the reason, but having none, I am grasping at straws. And I > have pulled out a straw that is very similar to the one Alex has pulled > out as well. I am at a point now where I really don't care why this is > happening (well, I do, but I am really tired of this...). So, my hope is > that if I go back to Perl 5.6.0, hopefully the Perl/Apache/mod_perl > combo will start working again. Worked for me. Just be sure that any reasons you may have installed 5.6.1 in the past don't apply still. You could lose the ability to use a module. Good luck... keep me posted. :) -Alex == Email: [EMAIL PROTECTED] Website: http://www.beardeddragon.org/ ==
Re: mod_perl stopped working...
obviously, right the load and add module lines for mod_erl are commented out. But, the rigmarole is the same... 1. I start the computer; Apache is not working. 2. Try to restart it; it doesn't work (no errors). 3. I comment out the lines (as below), start Apache; it works. 4. I uncomment the lines, restart Apache; mostly it works, although sometimes I have to do the step 3 and then step 4 again. On Thursday, April 11, 2002, at 09:34 AM, Puneet Kishor wrote: > = begin httpd.conf > ## > ## httpd.conf -- Apache HTTP server configuration file > ## > > ### Section 1: Global Environment > # > # Dynamic Shared Object (DSO) Support > > #LoadModule perl_modulelibexec/httpd/libperl.so > LoadModule hfs_apple_module libexec/httpd/mod_hfs_apple.so > > ClearModuleList > > #AddModule mod_perl.c > AddModule mod_hfs_apple.c
Re: mod_perl stopped working...
On Thu, 11 Apr 2002 19:20:00 +1000, Ken Williams wrote: > > However, I figured it out. I had updated perl to 5.6.1 when > > installing a module through CPAN. > > Don't you hate it when that happens? Yeah, although I don't think it does it automatically in OS X. The compile fails, due to HFS's case insensitivity (more annoying) and a file called "INSTALL" which is a text file. Also, there's a hints file that would put Perl in the wrong location (library wise). > > My other Mac that was working still had 5.6.0. So, I decided to > > downgrade perl back to 5.6.0. > > > > Voila! Apache now starts with mod_perl loaded. > > > > Probably not a great solution in general, since many > dependency-checkers assume you're only going to be moving *up* > in version numbers. Although I would generally agree with you on this, it's not an issue with me. Any modules that I installed on this machine that required Perl 5.6.1 was just me playing around or being curious. Actually, I think it came down to me trying to get IPC::Shareable working (still haven't). Maybe I ought to make that another thread after I check the archives for info on it. > A better solution would probably be to leave 5.6.1 installed (by > upgrading or going back in time), and reinstall mod_perl. I am curious if the other way around would work. It indeed it was some dynamic linking in libraries, reinstalling 5.6.1 might have the same effect as 5.6.0. I may try both, but I don't see any immediate need for that right now. Thanks for the tips... I'm just glad it's working. :) -Alex == Email: [EMAIL PROTECTED] Website: http://www.beardeddragon.org/ ==
Re: mod_perl stopped working...
Chris, (Alex), On Thursday, April 11, 2002, at 09:05 AM, Chris Devers wrote: > > It's only a partial remedy, but are your mod_perl related config > statments > wrapped in an appropriate block? > > > PerlSendHeader On > PerlHandler Apache::Registry > AddHandler perl-script .mpl > > see my httpd.conf below... > Etc. That might help to compartmentalize the errors. If you have > continuing errors though, you might want to look over the archives of -- > and maybe sign up for -- the mod_perl list. Chances are this is a > general > mod_perl issue, as opposed to a specific MacOSX issue. See > lists.perl.org > if it is a general mod_perl issue then it should be happening to, and be well documented for, a lot of other users. I have done some bg search on this, and not found anyone else experiencing the same symptoms. That is, until Alex wrote in his email. I have started experiencing these problems on my iBook ever since I upgraded Perl to 5.6.1. On my Powerbook, where Perl is still at 5.6.0, there is no such problem at all. I don't know the reason, but having none, I am grasping at straws. And I have pulled out a straw that is very similar to the one Alex has pulled out as well. I am at a point now where I really don't care why this is happening (well, I do, but I am really tired of this...). So, my hope is that if I go back to Perl 5.6.0, hopefully the Perl/Apache/mod_perl combo will start working again. Maybe there should be a Perl-triad, analogous to the PHP-Apache-MySQL triad that has become so popular. One install, and boom! you get a web-server, a scripting language, and a database all configured to talk with each other without a problem. fwiw, below are the perl-specific fragments from my httpd.conf = begin httpd.conf ## ## httpd.conf -- Apache HTTP server configuration file ## ### Section 1: Global Environment # # Dynamic Shared Object (DSO) Support LoadModule config_log_module libexec/httpd/mod_log_config.so LoadModule mime_modulelibexec/httpd/mod_mime.so LoadModule negotiation_module libexec/httpd/mod_negotiation.so LoadModule includes_modulelibexec/httpd/mod_include.so LoadModule autoindex_module libexec/httpd/mod_autoindex.so LoadModule dir_module libexec/httpd/mod_dir.so LoadModule cgi_module libexec/httpd/mod_cgi.so LoadModule asis_modulelibexec/httpd/mod_asis.so LoadModule imap_modulelibexec/httpd/mod_imap.so LoadModule action_module libexec/httpd/mod_actions.so LoadModule userdir_module libexec/httpd/mod_userdir.so LoadModule alias_module libexec/httpd/mod_alias.so LoadModule rewrite_module libexec/httpd/mod_rewrite.so LoadModule access_module libexec/httpd/mod_access.so LoadModule auth_modulelibexec/httpd/mod_auth.so LoadModule setenvif_modulelibexec/httpd/mod_setenvif.so #LoadModule perl_modulelibexec/httpd/libperl.so LoadModule hfs_apple_module libexec/httpd/mod_hfs_apple.so ClearModuleList AddModule mod_so.c AddModule mod_log_config.c AddModule mod_mime.c AddModule mod_negotiation.c AddModule mod_include.c AddModule mod_autoindex.c AddModule mod_dir.c AddModule mod_cgi.c AddModule mod_asis.c AddModule mod_imap.c AddModule mod_actions.c AddModule mod_userdir.c AddModule mod_alias.c AddModule mod_rewrite.c AddModule mod_access.c AddModule mod_auth.c AddModule mod_setenvif.c #AddModule mod_perl.c AddModule mod_hfs_apple.c # begin: added by pk, Feb 15, 2002 ### Perlrequire /Library/WebServer/Documents/startup.pl # end: added by pk, Feb 15, 2002 ### # begin: added by pk, Jan 28, 2002 ### SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI # end: added by pk, Jan 28, 2002 ## begin: added by pk, Jan 28, 2002 SetHandler perl-script PerlHandler Apache::Status order deny,allow deny from all allow from localhost ## end: added by pk, Jan 28, 2002 # include user-specific conf files (added by pk, Mar 18, 2002) Options Indexes MultiViews +ExecCGI AllowOverride None Order allow,deny Allow from all = end httpd.conf ==
Re: mod_perl stopped working...
On Thu, 11 Apr 2002 10:05:46 -0400 (EDT), Chris Devers wrote: > But isn't it supposed to not work unless it offers error messages? You would think so, but there are no error messages pertaining to a problem. And Apache ends up not running. I think that is the most disturbing thing. > It's only a partial remedy, but are your mod_perl related config statments > wrapped in an appropriate block? > > > PerlSendHeader On > PerlHandler Apache::Registry > AddHandler perl-script .mpl > Well, the thing is, I don't think it even gets that far in executing the conf file. In my case, I'm suspecting that something in the current mod_perl installation was conflicting with the perl 5.6.1. Although, this is generally a cleaner design of the conf file, it isn't helpful in this case. The LoadModule line seems to make Apache abort startup altogether. > and maybe sign up for -- the mod_perl list. Chances are this is a general > mod_perl issue, as opposed to a specific MacOSX issue. See lists.perl.org > and, specifically (but among others) the mod_perl users' list at > http://lists.perl.org/showlist.cgi?name=modperl-user Possibly, although I'm suspecting this is something just with OS X. I am wondering if the mod_perl library was reinstalled with the new Apache (probably), which had some dynamic linking done, designed for perl 5.6.0 (or possibly vice-versa), and the updated copy got "out of sync" with the newer perl. I spent a lot of time looking into this, in several other sites, several web searched, and a couple lists. *shrug* Definitely not something that seems to occur very often, except to Puneet and I. heh. -Alex == Email: [EMAIL PROTECTED] Website: http://www.beardeddragon.org/ ==
Re: mod_perl stopped working...
On Thu, 11 Apr 2002, Puneet Kishor wrote: > I think I wrote too soon... my Apache/mod_perl combo is back to the same > as it was... that is, not working without any error messages. But isn't it supposed to not work unless it offers error messages? ;) It's only a partial remedy, but are your mod_perl related config statments wrapped in an appropriate block? PerlSendHeader On PerlHandler Apache::Registry AddHandler perl-script .mpl Etc. That might help to compartmentalize the errors. If you have continuing errors though, you might want to look over the archives of -- and maybe sign up for -- the mod_perl list. Chances are this is a general mod_perl issue, as opposed to a specific MacOSX issue. See lists.perl.org and, specifically (but among others) the mod_perl users' list at http://lists.perl.org/showlist.cgi?name=modperl-user -- Chris Devers[EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ "More war soon. You know how it is."-- mnftiu.cc
Re: mod_perl stopped working...
Alex, I think I wrote too soon... my Apache/mod_perl combo is back to the same as it was... that is, not working without any error messages. I am really getting sick of this. On Thursday, April 11, 2002, at 02:48 AM, Alex S wrote: > Alex S wrote: > >>> I know this doesn't help you much, but maybe it will give some >>> insights. >> >> >> Thanks for the response. I think my next step will be to download the >> update and try to rerun it manually. Maybe the update had some minor, >> unreported failure when I ran it. > > > Okay.. well, the manual reprocessing of the update didn't help. > > However, I figured it out. I had updated perl to 5.6.1 when installing > a module through CPAN. My other Mac that was working still had 5.6.0. > So, I decided to downgrade perl back to 5.6.0. > > Voila! Apache now starts with mod_perl loaded. > I think I will do the same, and wait for Perl to be updated by Apple. Btw, I did the same as you... updated the stock 5.6.0 to 5.6.1, and that is when I started seeing these problems. Could you please tell me how to downgrade back to 5.6.0. I _really_ need to do that. Many tia, pk/
Re: mod_perl stopped working...
On Thursday, April 11, 2002, at 05:48 PM, Alex S wrote: > > However, I figured it out. I had updated perl to 5.6.1 when > installing a module through CPAN. Don't you hate it when that happens? > My other Mac that was working still had 5.6.0. So, I decided to > downgrade perl back to 5.6.0. > > Voila! Apache now starts with mod_perl loaded. > Probably not a great solution in general, since many dependency-checkers assume you're only going to be moving *up* in version numbers. A better solution would probably be to leave 5.6.1 installed (by upgrading or going back in time), and reinstall mod_perl. -Ken
Re: mod_perl stopped working...
Alex S wrote: >> I know this doesn't help you much, but maybe it will give some insights. > > > Thanks for the response. I think my next step will be to download the > update and try to rerun it manually. Maybe the update had some minor, > unreported failure when I ran it. Okay.. well, the manual reprocessing of the update didn't help. However, I figured it out. I had updated perl to 5.6.1 when installing a module through CPAN. My other Mac that was working still had 5.6.0. So, I decided to downgrade perl back to 5.6.0. Voila! Apache now starts with mod_perl loaded. I hope that anyone else who has had problems like these finds this helpful. Cheers, -Alex
