You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by "Brawn, Nicholas" <Ni...@vodafone.com.au> on 2003/08/07 06:21:10 UTC
OpenBSD 3.3 notes
Just set rivet on OpenBSD 3.3 (sparc64 in this instance). The following are
issues I resolved in getting it working:
1. Openssl crypto library isn't called libcrypt - it is called libcrypto.
Simple make.tcl edit, but something that might burn people down the track.
2. OpenBSD 3.3 has apache 1.3.27 built and installed with the default system
(good!), but runs chrooted by default. This breaks the loading of the
RivetTcl package.
Two options for resolution includes either a) moving RivetTcl package to
somewhere under it's chrooted directory (/var/www) and modifying auto_path.
Or b) setting httpd startup flags in /etc/rc.conf to be "-u" (which turns
off chrooting).
Cheers,
Nick
--
Vodafone Security Engineer - Contractor
Desk: (02) 9415 7017, Mobile: 0410 145 509
Email: nicholas.brawn@vodafone.com.au
**********************************************************************
A new world of colour, sound and pictures awaits you:
Vodafone Live! More details at http://www.vodafone.com.au/live/
**********************************************************************"
This correspondence is for the named person's use only. It may
contain confidential or legally privileged information or both. "
No confidentiality or privilege is waived or lost by any "
mistransmission. If you receive this correspondence in error, please
immediately delete it from your system and notify the sender. You
must not disclose, copy or rely on any part of this correspondence
if you are not the intended recipient.
Any views expressed in this message are those of the individual sender,
except where the sender expressly, and with authority, states them to
be the views of Vodafone.
This email has been checked for viruses.
**********************************************************************************************
Re: make.tcl vs configure/autoconf (was: Re: OpenBSD 3.3 notes)
Posted by "David N. Welton" <da...@dedasys.com>.
Nicholas Brawn <nc...@users.sourceforge.net> writes:
> On Fri, 08 Aug 2003 23:24:01 +0200, David N. Welton
> <da...@dedasys.com> wrote:
> > My original reasoning was something like this:
> > *) Configure doesn't run on windows. Well, it does, but you have
> > to get a bunch of cygwin stuff.
> > *) I hate configure and the auto* tools. With a passion. I
> > wanted to try my hand at making something that works better.
> > After having used make.tcl it for a while...
> > *) It doesn't appear to work on windows, because Tcl doesn't
> > include the right information in tclConfig.sh anyway. Most
> > windows people just want a binary build in any case.
> This could be approached the same way Tcl itself handles it. One
> build subdirectory for Unix, another for Windows.
Those aren't just for builds though - Tcl has different files on each
system, so those directories are very useful to keep the files
seperated out.
> > *) I think we still have a lot of room to maneuver, and would
> > still rather figure out how to make this work for you than install
> > a bunch of clunky conf* stuff. How does configure pick up the
> > information about libcrypt?
> I think configure would possibly identify the base OS, and from that
> recognise which library name the OS calls OpenSSL.
SSL? Nope. crypt() is just to be able to do one-way encryption, say,
for passwords. I guess I didn't catch that in your original email...
I had a look at a few configure scripts, and they just try and do a
compile with -lcrypt. Does OpenBSD just have crypt() 'built-in',
or...?
> > *) One thing that needs to happen is to keep pressuring the TCT to
> > include information in Tcl about how Tcl was built. TIP #59 was a
> > start to this (I think that's the right number).
> We could steal what Expect uses in its configure script for
> this. You simply give the configure script the path to your
> tclConfig.sh and I believe it picks up the relevant information.
That's what the current build scripts do, basically. A shell script
is not the greatest way of comunicating the information though, IMO.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: OpenBSD 3.3 notes
Posted by "David N. Welton" <da...@dedasys.com>.
Nicholas Brawn <nc...@users.sourceforge.net> writes:
> ><snip>
> > > 1. Openssl crypto library isn't called libcrypt - it is called
> > > libcrypto. Simple make.tcl edit, but something that might burn
> > > people down the track.
> >Yes, this has been mentioned before. I'm not sure what the best
> >way is to handle this... any ideas?
> Perhaps Rivet should go down the evil path of the ./configure
> script. This would eliminate most of the platform issues, or at
> least provide the end-user with a command-line option for specifying
> path to the openssl library.
> Plus, most people from the open source Unix world are well trained
> in the tar zxvf somepackage.tgz ; cd somepackage/ ; ./configure ;
> make install routine. The current make.tcl method is "strange" (it
> seemed so to me at first). I don't know about the historical
> decision that led to using make.tcl, but perhaps it should be
> revisited.
My original reasoning was something like this:
*) Configure doesn't run on windows. Well, it does, but you have to
get a bunch of cygwin stuff.
*) I hate configure and the auto* tools. With a passion. I wanted to
try my hand at making something that works better.
After having used make.tcl it for a while...
*) It doesn't appear to work on windows, because Tcl doesn't include
the right information in tclConfig.sh anyway. Most windows people
just want a binary build in any case.
*) I think we still have a lot of room to maneuver, and would still
rather figure out how to make this work for you than install a
bunch of clunky conf* stuff. How does configure pick up the
information about libcrypt?
*) One thing that needs to happen is to keep pressuring the TCT to
include information in Tcl about how Tcl was built. TIP #59 was a
start to this (I think that's the right number).
[ chrooting ]
> Well OpenBSD themselves have this to say about CGI and the chroot
> HTTPD environment
> (http://www.openbsd.org/faq/faq10.html#httpdchroot):
> <quote>
> Existing Apache modules: Virtually all will load, however some may not
> work properly in chroot(2), and many have issues on
> "apachectlrestart", generating an error, which causes httpd(8) to exit.
> Existing CGIs: Most will NOT work as is. They may need programs or
> libraries outside /var/www. Some can be fixed by compiling so they are
> statically linked (not needing libraries in other directories), most
> may be fixed by populating the /var/www directory with the files
> required by the application, though this is non-trivial and
> requires considerable programming knowledge -- most users will find it
> easier to just disable the chroot(2) feature until they are updated.
> <italics mine>
> In some cases, the application or configuration can be altered to
> run within the chroot. In other cases, you will simply have to
> disable this feature using the -u option for httpd(8) in
> /etc/rc.conf. </quote>
What do they do with PHP? Even that's not very comparable, because I
don't think it has so much external baggage. If you do a system call
trace of tclsh as it starts up, you notice that it fetches a lot of
stuff, most of which you would have to put in the chroot (like expect,
in your case, if you want to use that).
> Looks like it will be a pain in the ass to get working. I suspect
> the only way forward is to run it on a non-chrooted server. I can
> try testing by updating the default auto_path for tclsh and put the
> RivetTcl package under the chroot tree (/var/www in my case). You'll
> need to let me know how to do the auto_path stuff though - not sure
> how to do it.
auto_path is an ordinary Tcl variable, so you can just use list
commands to manipulate it.
Thanks for the input - it helps!
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: OpenBSD 3.3 notes
Posted by Nicholas Brawn <nc...@users.sourceforge.net>.
><snip>
> > 1. Openssl crypto library isn't called libcrypt - it is called
> > libcrypto. Simple make.tcl edit, but something that might burn
> > people down the track.
>
>Yes, this has been mentioned before. I'm not sure what the best way
>is to handle this... any ideas?
>
Perhaps Rivet should go down the evil path of the ./configure script. This
would eliminate most of the platform issues, or at least provide the
end-user with a command-line option for specifying path to the openssl
library. Plus, most people from the open source Unix world are well trained
in the tar zxvf somepackage.tgz ; cd somepackage/ ; ./configure ; make
install routine. The current make.tcl method is "strange" (it seemed so to
me at first). I don't know about the historical decision that led to using
make.tcl, but perhaps it should be revisited.
> > 2. OpenBSD 3.3 has apache 1.3.27 built and installed with the
> > default system (good!), but runs chrooted by default. This breaks
> > the loading of the RivetTcl package.
>
> > Two options for resolution includes either a) moving RivetTcl
> > package to somewhere under it's chrooted directory (/var/www) and
> > modifying auto_path.
>
> > Or b) setting httpd startup flags in /etc/rc.conf to be "-u" (which
> > turns off chrooting).
>
>Yeah, this is sort of a mess. Because you not only need the RivetTcl
>package, but all of Tcl, right? At that point, your chroot starts to
>look kind of bloated, and it would be better to go with option -b, I
>think. Maybe we can have something to that effect in the docs. What
>should it say?
Well OpenBSD themselves have this to say about CGI and the chroot HTTPD
environment (http://www.openbsd.org/faq/faq10.html#httpdchroot):
<quote>
Existing Apache modules: Virtually all will load, however some may not work
properly in chroot(2), and many have issues on "apachectlrestart",
generating an error, which causes httpd(8) to exit.
Existing CGIs: Most will NOT work as is. They may need programs or
libraries outside /var/www. Some can be fixed by compiling so they are
statically linked (not needing libraries in other directories), most may be
fixed by populating the /var/www directory with the files
required by the application, though this is non-trivial and requires
considerable programming knowledge -- most users will find it easier to
just disable the chroot(2) feature until they are updated.
<italics mine>
In some cases, the application or configuration can be altered to run
within the chroot. In other cases, you will simply have to disable this
feature using the -u option for httpd(8) in /etc/rc.conf.
</quote>
Looks like it will be a pain in the ass to get working. I suspect the only
way forward is to run it on a non-chrooted server. I can try testing by
updating the default auto_path for tclsh and put the RivetTcl package under
the chroot tree (/var/www in my case). You'll need to let me know how to do
the auto_path stuff though - not sure how to do it.
Cheers,
Nick
Re: OpenBSD 3.3 notes
Posted by "David N. Welton" <da...@dedasys.com>.
"Brawn, Nicholas" <Ni...@vodafone.com.au> writes:
> Just set rivet on OpenBSD 3.3 (sparc64 in this instance). The
> following are issues I resolved in getting it working:
Cool, thanks for letting us know!
> 1. Openssl crypto library isn't called libcrypt - it is called
> libcrypto. Simple make.tcl edit, but something that might burn
> people down the track.
Yes, this has been mentioned before. I'm not sure what the best way
is to handle this... any ideas?
> 2. OpenBSD 3.3 has apache 1.3.27 built and installed with the
> default system (good!), but runs chrooted by default. This breaks
> the loading of the RivetTcl package.
> Two options for resolution includes either a) moving RivetTcl
> package to somewhere under it's chrooted directory (/var/www) and
> modifying auto_path.
> Or b) setting httpd startup flags in /etc/rc.conf to be "-u" (which
> turns off chrooting).
Yeah, this is sort of a mess. Because you not only need the RivetTcl
package, but all of Tcl, right? At that point, your chroot starts to
look kind of bloated, and it would be better to go with option -b, I
think. Maybe we can have something to that effect in the docs. What
should it say?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org