final build.

Phil Howard phil-openssh-unix-dev at ipal.net
Wed Jun 26 15:57:12 EST 2002


On Tue, Jun 25, 2002 at 11:01:01PM -0500, Ben Lindstrom wrote:

| Do note this is a test snapshot.  Don't get comfortable, and what static
| issues are left?

The stock 3.3p1 works for me, too.  I guess it's the 2.4.18 kernel that
makes the difference. fpr mmap(), through I don't understand yet what
that difference is supposed to be.  I'm still trying to figure out what
code is running in the privsep child.

As for the static, I tried applying the patch you posted for 3.2.3p1
that was changing the getopt() calls around to avoid a conflict with
getopt() from glibc.  Apparently something else (in openssl or zlib,
maybe) was referencing something in getopt() that the OpenBSD flavor
included in OpenSSH didn't have, so the glibc version got loaded, too.
The current error message stopping the static compile is:

=============================================================================
gcc -g -O2 -Wall -Wno-uninitialized -I. -I.  -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ssh-agent.c
ssh-agent.c: In function `main':
ssh-agent.c:975: `BSDoptarg' undeclared (first use in this function)
ssh-agent.c:975: (Each undeclared identifier is reported only once
ssh-agent.c:975: for each function it appears in.)
make: *** [ssh-agent.o] Error 1
make failed
=============================================================================

I don't need to have static executeables immediately.  But I do need to
be on static executeables by the next time OpenSSL needs to be upgraded.
I have a lot of remote servers to manage and I use SSH to access them.
It is not practical to go driving around to each site to make changes on
the console (would take about 2-3 days to do that now).  And that's with
the 20 I have now all local.  The number is expanding and will soon have
most out of town.  I need to perfect the install from remote procedure.
The procedure I use now is to have multiple instances of sshd running on
different ports.  I take down one of the ports and update its executeable
and restart it, then test it.  While each works, this continues until all
the port instances are upgraded.  If the executeables are static this
works cleanly.  If the executeables are dynamic, this works cleanly if
the change does not involve the libraries sshd uses.  If the libraries
are updated, this frequently clobbers the running processes.  If the
library updates create a new version number, this is not a problem as
the old version is still present (until I clean it out later).  The big
problem is that OpenSSL does not name the libraries according to their
packaging version.  So the library name for 0.9.6c has 0.9.6, and then
when the upgrade to 0.9.6d is done, it clobbers the previous library
and all the sshd daemons listening on all the ports will seg fault and
then I'm locked out of access (except for 2 servers where I have dialup
serial console).  The install program, which almost every package uses
to install files into the system, is broken in principle because it
opens the existing file, truncates it, then writes the new binary data.
For executeables, I get "Text file busy" busy.  But libraries are not
locked, and do get clobbered.  I'm now experimenting with some scripts
to pre-build everything on a central machine under chroot, extract the
appropriate files (the script figures this out), distribute those to
remote machines (rsync via ssh), then run another script to "install"
the selected files by means of copying to a temporary name in the
appropriate directory and doing mv -f to replace.  However, this is
still running into library problems that I have not yet fully determined,
but it seems that when a file that is memory mapped, but not open, is
full unlinked, it really goes away.  Do that to a library which needs
to get swapped in and you still get a seg fault or some other error.
I think my next step is to make my installer script more sophisticated
and instead of just replacing a file with mv -f, it first links that
file to an "-old" name, then does the mv -f (and thus no process ever
sees an absent file).  Maybe if ld.so and libdl were to use the flag
MAP_EXECUTABLE on mmap() calls to load libraries, some of this might
have been less of a problem.



| On Tue, 25 Jun 2002, Phil Howard wrote:
| 
| > On Tue, Jun 25, 2002 at 08:52:13PM -0500, Ben Lindstrom wrote:
| >
| > | http://www.eviladmin.org/~mouring/openssh.tar.gz
| >
| > Works for me on:
| >     Slackware-8.0 (modified)
| >     Linux 2.4.18
| >     Glibc 2.2.3
| >     OpenSSL 0.9.6d
| >     Zlib 1.1.4
| > I simply started up the daemon and connected to it from the same
| > machine, and also from another machine running 3.2.3p1.  I also
| > cross checked that its client will still connect to 3.2.3p1 (so
| > I can do upgrades of all my remote servers once I figure out how
| > to get a clean static compile).
| >
| > --
| > -----------------------------------------------------------------
| > | Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| > | phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
| > -----------------------------------------------------------------
| >
| 
| _______________________________________________
| openssh-unix-dev at mindrot.org mailing list
| http://www.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------



More information about the openssh-unix-dev mailing list