Jump to content

ohh

Members
  • Posts

    11
  • Joined

  • Last visited

Contact Methods

  • Website URL
    http://flyingmoose.org

Profile Information

  • Location
    Seattle
  • Interests
    J.R.R. Tolkien, stagecraft, woodworking, old DEC minicomputers, and many other activities which would doubtless horrify you

ohh's Achievements

Rookie

Rookie (2/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. That was incredibly fast. Yes, "+Includes" seems to have made everything happy and working again. Thank you!
  2. Hi! I've had my website, flyingmoose.org, on R2D2 at TCH since 2008. Most of my pages have a Server-Side Include embedded near the bottom, and these call Perl scripts in my public_html/cgi-bin directory - usually to do simple things like keep count of page accesses, but a few of the scripts are more complex (such as an Error 404 page-generator). I noticed recently that the page-counters weren't showing any progress, and today realized that's because all the CGI scripts have stopped working. In place of the Perl script's output, all I have now is the message "[an error occurred while processing this directive]". Today I replaced one of the more common scripts in my cgi-bin with a simple script which does nothing but print a line of output, and gave it very broad permissions. It gave the same error. Nothing else has changed on my end, and an e-mail sent by one of the scripts shows they were working as recently as 25 July. Has there been a configuration change on R2D2 which would explain this? In any event, any suggestions for how to fix it? Thanks!
  3. Damn, you guys are quick. All better now! Out of curiosity, is there a short version of what happened? Thanks!
  4. I have a handful of secure CGI scripts running on my pages at http://flyingmoose.org. Until a day or two ago, they were all working fine. Now, today, none of them are working. There have been no changes to anything at my end. They all report the error: scgiwrap: Caller must be the nobody user Has something changed at the server end to derail secure CGI scripts? If so, how can it be set right?
  5. Uhm, could we double-check this? date seems to be located at /bin/ - at least, it functions there but doesn't at /usr/local/. I'm not yet sure about rm and ls.
  6. Excellent. Thanks very much!
  7. Is this true for a Perl script running from /scgi-bin as well? On the last two servers I was on, for Perl scripts that ran as setuid, Perl considered the $PATH environment variable as potentially tainted - and so Perl would reject it, meaning I had to call rm, date and ls with full paths. This is normal behavior for setuid'd Perl, or at least it was when I learned it. Of course, that was a few incarnations of Perl ago.
  8. This should be simple enough to answer, I hope. I'm in the process of moving my site over to TCH. It has a fair amount of CGI calls buried in it: most of it very low-level and straightforward, but there are a couple of scripts which call on other parts of UNIX for help. I've got the paths for Perl and sendmail - they're hard to miss, being listed on the main page of CPanel and all. What are the paths for rm, date and ls? I'm guessing just /bin. But, er, I'd rather not guess. Thanks!
×
×
  • Create New...