Re: First CGI Setup

[Joel Rees]

According to the Apache error logs, I'm connecting okay, but something 
seems to
be off.i've been reading up on the config issues, and I've worked thru 
some of
them, but frankly I'm out of my element,
Yeah, MSWindows to *nix can be an exciting leap.
 and concerned about munging up httpd.conf
so badly I'll be sent away.
Backups. You do keep backups, right?
(One of these days I'm going to get version control running to my 
liking, and I'll keep everything under /etc in version control. For 
now, I just make a copy to work on and rename the old one *_nnn.bak or 
something, keeping track of the editing sequence in the _nnn portion.)

The script..
#!/usr/bin/perl -w
print "Content-type: text/html\n\n";
print "Hello, World!\n";
...shows up in safari with the script text, but with "Hello World" in 
the header
font style!
Yeah,  tends to do that.
As to why your browser is interpreting it as HTML when the Content-type 
declaration is too late, I couldn't say. Maybe the file name extension 
encouraged Apache to automatically put a Content-type of html into the 
stream ahead of the source?

!/usr/bin/perl -w  print "Content-type: text/html\n\n";  print "
Hello, World!
\n";
These are (AFAIK) the relevant httpd parts. Note that I was following 
a tutorial
on the O'reilly site, and one here 

and made the most progress with using my own home directory (as 
opposed to
/Lib/./CGI-Exe).
Fewer permissions issues there, yes. But that may not be a good thing, 
depending on whether or not you have that server facing the web.

 (I'm not sure what makes the most sense, just for
at-home development. I'd imagine the more real-world setup is better)
I've custom partitioned my hard drive. Most of my Unix apps (except for 
the default Apple installed ones) are installed on UFS partitions, and 
everything I have facing the web is on UFS, as well.

That meant that when one of the vulnerabilities about the Macintosh 
file types was published recently, I was ahead of the curve a bit.

In order to do that, I've had to be fairly careful with permissions and 
owners and such. Symbolic links to each user's web stuff placed in each 
user's home folder make it not too inconvenient to have the web stuff 
on its own partition.

I've set each user's web-facing directories and files to owned by user, 
but group is the apache user. The directories that serve the domain 
root are owned by the apache user. Directory permissions are 
read/write/search (rwx) for owner, read/search (r-x) for group, no 
permissions (---) for others.


AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch Includes ExecCGI
DirectoryIndex index.html index.cgi

Order allow,deny
Allow from all


Order deny,allow
Deny from all


This is in /etc/httpd/users , right?
and...
# To use CGI scripts:
#
#AddHandler cgi-script .cgi
#
# To use server-parsed HTML files
#
#AddType text/html .shtml
#AddHandler server-parsed .html
I personally am a bit of a bigot about file extensions. I don't use 
them except for perl because I don't have to, and because I prefer to 
have all my cgi in one place.

I put the cgi directory enabling directives in each users configuration 
in /etc/httpd/users :

ScriptAlias /~user/cgi/ "/Volumes/uw/users/user/cgi"

AllowOverride None
Options None
Order allow,deny
Allow from all


The log says this (which to my eyes looks better than what I've seen 
before

[Wed Mar  9 16:51:37 2005] [notice] Apache/1.3.33 (Darwin) PHP/4.3.2 
configured -- resuming normal operations
[Wed Mar  9 16:51:37 2005] [notice] Accept mutex: flock (Default: 
flock)
That simply means Apache parsed it succesfully. Lack of syntax errors 
does not mean conformance to some set of goals, even if you know what 
those goals are.

Yikes! This is long!
So's httpd.conf . ;-)

Re: First CGI Setup

[Chris Devers]

On Sat, 12 Mar 2005, Joel Rees wrote:

> (One of these days I'm going to get version control running to my 
> liking, and I'll keep everything under /etc in version control. For 
> now, I just make a copy to work on and rename the old one *_nnn.bak or 
> something, keeping track of the editing sequence in the _nnn portion.)

Try this:

$ cat ~/bin/stamp
#!/bin/bash
#
# stamp is a utility which makes a backup of a conf file

[ $# -ne 1 ] && echo "usage: `basename $0` filename" && exit 100

old="$1"
new="$1.`date +%Y%m%d`.$$"

[ ! -f $old ] && echo "$old does not exist" && exit 100

cp $old $new

status=$?

[ -x $new ] && chmod -x $new

exit $status
$

It's crude, but it works well enough.

$ cd /etc/httpd
$ sudo stamp httpd.conf
  # I get a file like "httpd.conf.20050311.15629".
$ vim httpd.conf && apachectl configtest
  # I make a royal mess of things. Damn.
$ cp httpd.conf.20050311.15629 httpd.conf
$ apachectl configtest
  # All is right with the world again.

Something like CVS / SVN / BitKeeper would be "better", but not easier.
 


-- 
Chris Devers

Any interest in a CamelBones CVS snapshot?

[Sherm Pendley]

Is anyone interested in a CamelBones CVS snapshot?
The framework is *not* in a release-quality state. It leaks memory 
rather badly. It hasn't been tested very much on Tiger, and not at all 
on Jaguar. There is no build target for an app-embedded framework yet. 
XS wrappers for non-OO AppKit functions aren't written yet.

And yet, despite all that - the parts of it that *are* done work well 
on Panther. All of the examples work, and I've added a number of new 
examples that demonstrate newly supported features like Cocoa Bindings 
support, document-based apps, Perl objects in nibs, custom views and 
custom windows. It may not all be there yet, but what *is* there is 
solid enough to develop with.

With that in mind - is anyone interested in a CVS snapshot release?
(I'm posting this question to the camelbones-devel list at SF too - 
apologies to those of you who subscribe to both.)

sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Re: First CGI Setup

[Wiggins d'Anconia]

Chris Devers wrote:
On Sat, 12 Mar 2005, Joel Rees wrote:

(One of these days I'm going to get version control running to my 
liking, and I'll keep everything under /etc in version control. For 
now, I just make a copy to work on and rename the old one *_nnn.bak or 
something, keeping track of the editing sequence in the _nnn portion.)

Try this:
$ cat ~/bin/stamp
#!/bin/bash
#
# stamp is a utility which makes a backup of a conf file
[ $# -ne 1 ] && echo "usage: `basename $0` filename" && exit 100
old="$1"
new="$1.`date +%Y%m%d`.$$"
[ ! -f $old ] && echo "$old does not exist" && exit 100
cp $old $new
status=$?
[ -x $new ] && chmod -x $new
exit $status
$
It's crude, but it works well enough.
$ cd /etc/httpd
$ sudo stamp httpd.conf
  # I get a file like "httpd.conf.20050311.15629".
$ vim httpd.conf && apachectl configtest
  # I make a royal mess of things. Damn.
$ cp httpd.conf.20050311.15629 httpd.conf
$ apachectl configtest
  # All is right with the world again.
Something like CVS / SVN / BitKeeper would be "better", but not easier.
 


Nice. You could also just op for RCS until you can get a more managed 
solution up, it works well enough for this type of thing and only (or 
not even) requires an RCS directory be created, and for you to follow 
the standard procedures,

> co -l filename
... make edits
> ci -u -M filename
Pretty simple stuff. It appears rcs comes with Mac OS X, or at least 
when the dev tools are installed.

> man rcs
For more info.  The others are excellent, but they can be overkill for 
simple, non-distributed, configuration files.

http://danconia.org

Re: Any interest in a CamelBones CVS snapshot?

[Pierre Vaudrey]

Sherm,
Le 11 mars 05, à 18:34, Sherm Pendley a écrit :
With that in mind - is anyone interested in a CVS snapshot release?
Interested to test Shux with the new frameworks with Panther... and 
some help from you.

Pierre