buildworld is broken on the system without 'crypto' distribution
It seems that libcrypto.so.2 is requied to complete buildworld. I got following errors on 4.6-RELEASE system with only 'bin' distribution installed while trying to build recent -stable (it builds ok on another box with 'crypto' installed): === secure/usr.bin/scp cc -O -pipe -I/data/FreeBSD/src/secure/usr.bin/scp/../../../crypto/openssh -DNO_IDEA -c /data/FreeBSD/src/secure/usr.bin/scp/../../../crypto/openssh/scp.c gzip -cn /data/FreeBSD/src/secure/usr.bin/scp/../../../crypto/openssh/scp.1 scp.1.gz cc -O -pipe -I/data/FreeBSD/src/secure/usr.bin/scp/../../../crypto/openssh -DNO_IDEA -o scp scp.o -lssh /usr/obj/data/FreeBSD/src/i386/usr/libexec/elf/ld: warning: libcrypto.so.2, needed by /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so, not found (try using -rpath or -rpath-link) /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_DigestInit' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_enc_null' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_CIPHER_CTX_init' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_rand' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `RSA_generate_key' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `PEM_read_PrivateKey' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_DigestFinal' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_bin2bn' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_CTX_new' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_value_one' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_bn2bin' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DSA_do_sign' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_sub' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `OBJ_nid2sn' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `PEM_write_DSAPrivateKey' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `HMAC_Final' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_md5' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_rc4' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DSA_generate_key' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `RSA_sign' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DH_generate_key' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DH_size' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_hex2bn' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_num_bits' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DSA_new' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DH_new' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `SSLeay' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DH_compute_key' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_sha1' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `RSA_private_decrypt' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DSA_free' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_CipherInit' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `RSA_new' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `CRYPTO_free' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_bn2dec' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_ripemd160' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `DSA_do_verify' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_PKEY_get1_DSA' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `MD5_Init' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `EVP_CIPHER_CTX_cleanup' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `RAND_status' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_dec2bn' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `RSA_public_encrypt' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `ERR_error_string' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `MD5_Final' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_mod' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so: undefined reference to `BN_is_bit_set' /usr/obj/data/FreeBSD/src/i386/usr/lib/libssh.so:
Plain text posting
Hi I have noticed an increased tendency of a few people to post to plain text lists using attachments. Quite apart from minor irritations such as increased bandwidth and the necessity to open attachments some people seem to have the mistaken impression that the practise of sending messages via a PGP signed attachments somehow adds to general recipient security rather than diminish it by encouraging careless attachment usage. It may be important to remember the general principle that the customary opening of attachments is inherently more risky than a plain text message for the recipent even when PGP signed. The less secure the operating system of the immediate recipent the more risky the practice. Viruses, which may not be able to infect a primary recipient often reach their targets by being forwared from a primary to a secondary recipent on a more vulnerable platform. PGP only tells us that the message has not changed in transit. A malformed/abusive/virus laden attachment is still malformed/abusive/virus laden even if PGP signed. Can we please stick to plain text UNLESS the material cannot reasonably be transmitted without being in attachment form. There is no benefit to be gained from attachments otherwise. Thanks David To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Hang problem with spamass-milter...
On Mon, Jul 08, 2002 at 05:20:04PM -0500, Dan Nelson wrote: In the last episode (Jul 08), Joe Talbott said: To repeat: for i in `jot 10 1`; do echo test $i | mail -s test $i [EMAIL PROTECTED] done Works for me. I changed `jot 10 1` to `jot 100 1` and after some chugging, got all 100 messages. With patch 349 applied, the milter uses a select() loop in the part of the code where it needs to both read and write from spamc, so I can't see where it would deadlock. After applying the updated 349 to a fresh CVS update I received all 10 of my test messages. I have always gotten the messages. Before my latest build the headers were not being added. After the update all 10 messages were correctly processed. However I have 4 spamc processes hanging around and 4 spamd processes hanging around. I sent you this in a private email along with -d2 level logs. It's possible you're seeing some sort of threading bug on -stable; I have only tested on -current. That's possible. I haven't had much time to dig into this. I also applied patch 372 which didn't solve the problem. 372 just sets all the sockets to non-blocking, which will cause buzz-loops, and adds some other bugs that make it not 8-bit clean for incoming messages. So you're saying I maybe should remove this patch from my builds? Thanks for your help, Joe -- Laziness is nothing more than the habit of resting before you get tired. Jules Renard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: system immutable files make mergemaster look funny
On Tue, Jul 09, 2002 at 02:15:00PM +0200, Erik Trulsson wrote: Do you wish to delete what is left of /var/tmp/temproot? [no] yes rm: /var/tmp/temproot/var/empty: Operation not permitted rm: /var/tmp/temproot/var: Directory not empty rm: /var/tmp/temproot: Directory not empty *** /var/tmp/temproot has been deleted Obviously, last sentence isn't true :-) Obviously?? It is actually true: /var/tmp/temproot actually is deleted afterwards (at least for a recent -stable). Hmm, you are right. Now using fresh -STABLE I see that it cleans all right. Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
intel etherexpress pro and fxp status??
Greets All: during the 4.6rc era i recall there were issues with intel ether pro and fxp drivers, particularly with smp boxes. Searching pr's i note there are numerous open issues as well. in the past the fbsd nic mantra has always been intel ether express. Is such still the case with the 82559 based nics (e.g. pila 8460), or should I be looking elsewhere? Note that one of my boxes is a dual pii 450 on a bx board. Please cc, as I am no longer subscribed to the list (thanks to the phb's) -- Regards, Ken Gunderson (non-HP) HP-UX Systems Administrator HP NAOD Front-line System Management Boise Server Support Team To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: No root crontab in 4.6-RELEASE?
* Jason Andresen ([EMAIL PROTECTED]): [/etc/crontab vs. crontab -u root] ??? More visible? New people to the system can never find that file. Heck, I'm always forgetting where it is. It wouldn't be so bad if it just weren't so inconsistent. See cron(8), second paragraph. -- Thomas Seck This message was sent to a mailinglist I am subscribed to. Please send your replies to the list - and do *not* CC me. Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: No root crontab in 4.6-RELEASE?
:* Jason Andresen ([EMAIL PROTECTED]): : :[/etc/crontab vs. crontab -u root] : : ??? More visible? New people to the system can never find that file. : Heck, I'm always forgetting where it is. It wouldn't be so bad if : it just weren't so inconsistent. : :See cron(8), second paragraph. : :-- :Thomas Seck : /etc/crontab should probably not be touched, nor should /etc/periodic, or upgrading the system will be nightmware. If you want to use the periodic mechanisms you can create your own periodic directory hierarchy ala /usr/local/etc/periodic, and if you just want to mess with your own root crontab you should use 'crontab -e' as root. If you want to override the system default /etc/periodic you can create your own /etc/periodic.conf (else the system uses the default /etc/defaults/periodic.conf). It's simple. See man periodic.conf. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: No root crontab in 4.6-RELEASE?
Date: Tue, 9 Jul 2002 09:51:03 -0700 (PDT) From: Matthew Dillon [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] :* Jason Andresen ([EMAIL PROTECTED]): : :[/etc/crontab vs. crontab -u root] : : ??? More visible? New people to the system can never find that file. : Heck, I'm always forgetting where it is. It wouldn't be so bad if : it just weren't so inconsistent. : :See cron(8), second paragraph. : :-- :Thomas Seck : /etc/crontab should probably not be touched, nor should /etc/periodic, or upgrading the system will be nightmware. If you want to use the periodic mechanisms you can create your own periodic directory hierarchy ala /usr/local/etc/periodic, and if you just want to mess with your own root crontab you should use 'crontab -e' as root. If you want to override the system default /etc/periodic you can create your own /etc/periodic.conf (else the system uses the default /etc/defaults/periodic.conf). It's simple. See man periodic.conf. Also, as far as I know, the use of local periodic(8) scripts via periodic.conf(5) entries in 999.local is supported. mergemaster(8) should catch changes in periodic.conf(5). R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Plain text posting
At 7:48 am -0700 9/7/02, vizion communication wrote: Hi [...snip...] Can we please stick to plain text UNLESS the material cannot reasonably be transmitted without being in attachment form. There is no benefit to be gained from attachments otherwise. I heartily concur. An additional problem is in message digests where the relationship between the attachment and the original message is lost. One finds onself scrolling through reams of base64. Robin. -- Robin Melville, Information manager Addiction Forensic Information Service Nottingham Healthcare NHS Tust Tel: +44 (0)115 952 9478 Fax: +44 (0)115 952 9421 email: [EMAIL PROTECTED] Pages: http://www.nadt.org.uk/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ssh to remote machines problem after cvsup
Jay Sachs wrote: There are those of us who consider the protocol switch a good change, So you are free to do that on your systems. The problem is, whether you think it's a good idea or not, it's already catching people by surprise, and locking them out of their systems. The change should be reverted. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
system immutable files make mergemaster look funny
That's what you get now after completing mergemaster: *** Comparison complete Do you wish to delete what is left of /var/tmp/temproot? [no] yes rm: /var/tmp/temproot/var/empty: Operation not permitted rm: /var/tmp/temproot/var: Directory not empty rm: /var/tmp/temproot: Directory not empty *** /var/tmp/temproot has been deleted Obviously, last sentence isn't true :-) Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ssh to remote machines problem after cvsup
Date: Tue, 09 Jul 2002 10:09:29 -0700 From: Doug Barton [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Jay Sachs wrote: There are those of us who consider the protocol switch a good change, So you are free to do that on your systems. The problem is, whether you think it's a good idea or not, it's already catching people by surprise, and locking them out of their systems. The change should be reverted. Doug, This was discussed on stable (admittedly a bit late in the game) and every comment I saw favored making the change in Stable. An entry was made in UPDATING to warn people of the change. From a security standpoint alone the change is justified as protocol V1.5 has long required kludges to work around its problems while V2 was much more carefully crafted from the ground up and has no known problems. I am only talking about the protocol and no particular implementation. People should really be using V2 protocols in all cases except where remote systems still don't support it. (And, do you REALLY want to connect to those systems?) I will admit that I had pretty much converted everything of mine to use V2 long before this came up, so this really didn't have an impact on me. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Linux Java 1.4 was: linux_base-7.1 problem
hi, On Mon, Jul 08, 2002 at 11:52:01AM -0700, Shannon -jj Behrens wrote: DWC On Wed, Jul 03, 2002 at 11:35:41AM -0600, Jason Porter wrote: glibc-2.1.2-11. It finally exists with an Error code 1 and stops the install. Anyone else have this problem? DWC This happens sometimes when there are leftovers in /compat/linux from DWC linux_base-6, if you can rm -fr /compat/linux/* and reinstall linux My experience is that linux_base-7.1 fails miserably with the acroread4 and acroread5 ports (fails to install them for lack of strip program), and then core dumps when you run acroread. Personally, I just went with linux_base6-6.1 and it works flawlessly. I noticed that linux_base-7 makes linux-sun-jdk14 crash, whereas linux_base-6 doesn't. This was from a completely clean /compat. Should I submit a PR, or is this known behavior. What was really surprising is that linux-sun-jdk14 will try to install linux_base-7 if linux_base-6 isn't installed, but this default results in a broken configuration. I hit to this problem also. I think root of problem is that official Linux release supported by jdk1.4 is RH 6.1 (as jdk building docs declare). And there're some fatal binary incompatibilities between RH 6.1 and 7.1 :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvs commit: ports/www/apache2 Makefile ports/www/apache2/files patch-modules:ht (fwd)
Thank you for pointing this out! It may indeed be what's wedging Apache 2.x. I may still downgrade to 1.3.26, though. The process size is smaller, and the only truly major difference between 1.3.x and 2.x is the new threading model, which FreeBSD can't use because pthreads are still a kludge. --Brett At 07:52 AM 7/9/2002, Cy Schubert - CITS Open Systems Group wrote: Brett, this is probably what you've been looking for . -- Cheers, Phone: 250-387-8437 Cy SchubertFax: 250-387-5766 Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED] Open Systems Group, CITS Ministry of Management Services Province of BC FreeBSD UNIX: [EMAIL PROTECTED] --- Forwarded Message Date:Tue, 09 Jul 2002 04:22:19 -0700 From:Hye-Shik Chang [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: ports/www/apache2 Makefile ports/www/apache2/files patch-m odules:http:http_request.c perky 2002/07/09 04:22:19 PDT Modified files: www/apache2 Makefile Added files: www/apache2/filespatch-modules:http:http_request.c Log: - Add a patch for a bug on infinite loop in HTTP_IN filter that allows DoS attack. - Bump PORTREVISION - Change maintainer address Obtained from: Apache Group CVS (rev 1.150-1.151) Revision ChangesPath 1.125 +2 -2 ports/www/apache2/Makefile 1.1 +10 -0 ports/www/apache2/files/patch-modules:http:http_r equest. c (new) --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
