Sun Web Server 7.0 and Perl and documentation rant
I have a very simple Hello World perl script which I want to run within my Web application. The Web application is set up on a Solaris system with Sun Web Server 7.0 Preview 3.0. There is absolutely no good documentation which provides a step-by-step guide on how to tell the Web server to run .pl files and show the output. HOW DOES IT WORK?
I created a test file called test.pl with:
#!/bin/perl
#
#
print"Content-type:text/html\n\n";
print"Hello World!";
When I "load" the file at, i.e. http://www.myserver.com/test.pl, the browser presents me with a download window - the server doesn't understand that it needs to execute the file via perl and show the output!!
BUT, when I rename the file to test.cgi, the Web server correctly processes the request and prints out "Hello World".
Why is setting up PERL applications so difficult? And why is the Web server's documentation so confusing and lacks good down to earth step-by-step guides that normal business users can understand (I understand that there might not be any 7.0 documentation available yet, but the 6.1 documentation is horrible - I've read through it - so please don't reply with only the link to the documentation).
Good documentation for setting up perl might look like this:
1. Assuming standard install on Unix, first do this
2. Then do this
3. Then do this
jetcat33
Message was edited by:
dailysun
[1528 byte] By [
dailysun] at [2007-11-26 11:59:26]
# 1
Do you have .pl as a mime type associated with your cgi?
From the documentation
"To change which extensions indicate CGI programs, modify the following line in the mime.types file to specify the desired extensions. Be sure to restart the server after editing mime.types.
type=magnus-internal/cgi exts=cgi,exe,bat "
Just add pl to that list. Is that not working for you?
# 2
The GUI Admin server interface confuses me - it's not the interface, but I don't understand how the servers are run now. The way I used WS 6.1 was by either making changes to the config files via command line vi (i.e. server.xml, etc) and then restarting the server, or by using the GUI interface and restarting the server.
Now, with WS7, things seem to revert back to old versions, when I make changes in the GUI and restart the instance, the actual config files don't have the changes in them. For instance, I just made sure to have the MIME type updated like you suggested: "magnus-internal/cgi cgi,exe,bat,pl". I made that change via the GUI. I then restarted the instance via the GUI. However, when I "more mime.types" to view the actual file, I see that it hasn't been updated?! Also, for some reason, the GUI keeps on wanting me to deploy a configuration - even when nothing has changed. Arg! This is very confusing. I understand this is still a preview, so I guess the confusion is still okay - that's a part of getting the program ready.
I think I'm going to scrap the GUI until the documentation gets better or I can spend a few weekends doing trial and error tests.
Okay, sorry, this is now what I have done using command line only:
1. In mime.types removed the "type=application/x-perl exts=pl". Otherwise I get a "pl defined twice" error when I restart the server.
2. In mime.types updated the cgi link to include the pl suffix: "type=magnus-internal/cgi exts=cgi,exe,bat,pl"
3. Restarted the server using /bin/stopserv and /bin/startserv
4. Tested pl in browser...
Outcome: The browser still presents me with the save box...
Am I missing anything? Thanks for your reply!
dailysun
# 3
I just tried this, and it worked for me. With one caveat, I needed to refresh the browsers cache - i.e. restart the browser.
After that the test.pl worked as you have it.
Regarding Admin Server, the way it works is that it has the concept of configurations. Configurations are a collection of config files which are kept in a config store and that can be deployed to one instance, no instances at all or several instances in different machines. They are essential for distributed management and cluster management.
You make all the changes to a configuration without affecting the instance until your changes are completed. Then you can deploy this changes to any number of instances you want. It does not apply the changes automatically because that will cause a lot of traffic between the administrative server and the administered instances.
If you change the files manually, the admin server will detect those changes, and ask you the pull them into the configuration.
I have notice that the admin server will think that the files have been changed if you have them open with certain editors (ex. vi). Once you quit the editor with no changes, then the admin will realize the configurations are synchronized, and not ask you to deploy.
# 4
Thanks for your reply. So that means: When I change server.xml in my https-server/config/ directory, the GUI asks whether it should take those changes and put them into the configuration "backup" files that it stores in the configuration store?Sincerely,dailysun
# 5
More or less, yes. That will be the "pull changes" options. That configuration can then be replicated to other nodes - if you have several instances running in a cluster. Remember it is done with distributed administration in mind - i.e. the admin server and the server instance don't have to be in the same machine.
