Re: Thread DIES [Re: ssh - are you nuts?!? ]
On 29 Dec, Wes Peters wrote: Bill Fumerola wrote: On Wed, Dec 27, 2000 at 04:04:36PM -0800, [EMAIL PROTECTED] wrote: Bill Fumerola, who states that security policy information is un-available. However, I might refer his comment to the Security Officer instead, if Bill feels this appropriate. for the public record: Its unavailable in a "I don't know of any place that it is currently stored publicly, so I have no idea how JmJr was making references to it"-way as opposed to a "It's super-secret-elite and you can't have it"-way. This is exactly what I meant when I wrote "we need to solve this problem." I.e., we need a published procedure for disseminating ssh keys for FreeBSD machines to those who need them. Simply publishing what is currently done, perhaps in the committer section of the Handbook or even in the committers instructions, would meet this need just fine. Boy, am I glad this is over. Wes, I reget that your response does not reference your original message. I have reposted your exact comments and your the Message ID to which your comments pertain. If you'd like me to repost that message, I will. Let me make clear that I believe your words and your intent. However, in light of your response being --un-referenced from the original-- , I must consider this response as NOT a repudiation* of earlier suggestions. *repudiation - rejecting as invalid respectfully, Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ssh - are you nuts?!?
On 28 Dec, Mark Murray wrote: Okay, can you be specific about what you mean by "There was a time that we were very lax". If there was a change of server identity, then we did not necessarily announce what the new identity was in a way that people could trust. These days, a member of the Security Officer team sends out an announcement (cryptograhically signed of course) letting folks know what identity (fingerprint) to expect. I'm sorry, but this opens up a can of worms. However, I've also promised further communications to be off-line. Anyone else, interested in this subject, email me and you'll be added to the CC on this issue. Please email ONLY from this message, else I cannot trace your request. Mark, Please expect my response in about 24 hours from the posting of this message. Respectfully, Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
console.h mouse.h
If you know little (or even larger ones) programs that could demonstrate console.h (consio,kbio,fbio) and/or mouse.h could you mail/reply here? I already found aumix. (I'm writing a small article. I found out a lot myself and via the manpages, but some things don't work (and a working duplicate would help to track the problem in the translated headers), and for some functions I haven't been able to find much. Thanks in advance! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot process robustness
John Baldwin wrote: On 28-Dec-00 Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], "Walter W. Ho p" writes: Hi all, I was wondering how to increase the robustness of the booting process, so that a box would be able to keep itself on its feet without intervention of the console. I think this would be of great value to the many people who administer colocated boxes. the old 'nextboot(8)' system used to do this if you had the 'writeback' option enabled.. it wrote a sequence of boot strings into block '1' (not 0) and zero'd them out as it used them up. /etc/rc would then be used to write an appropriate set of strings back in the case of a successful boot. This is used successfullly in the thousands of interjets out there in the field. Unfortunatly the new bootblock writers never considered this an important enough feature to emulate. but it gives you a place to look. We wrote a list of ever-increasingly conservative boot strings, eventually even moving to an alternate root partition I'm not much of a coder so all I can do is mailing this (at the risk of wasting your time with total useless crap ofcourse, in which case I apologize.) 1. Old kernel recovery When 'make install'ing a new kernel, a flag is raised (say, 'revert_on_fail') which is only cleared after a successful system initialisation. When the new kernel boots, a panic in this state or an unexpected reboot (reset after a system hang) would cause /kernel.old to be loaded on the next boot instead (maybe the same could work for /etc/rc.conf.old) This is actually more a question of where to store the flag than anything else. /boot/loader.conf perhaps, but how does the loader know that the previous boot failed so that it knows to fall back? This is much harder, as a failed kernel boot usually results in a hang or an instant CPU reset. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
On Fri, Dec 29, 2000 at 11:56:57AM +1300, David Preece wrote: At 10:12 28/12/00 -0700, you wrote: Lastly, search for quiet fans from a large supplier. http://www.quietpc.com/ I haven't bought any stuff from them, yet, so I can't vouch other than for their existence. I have. For 100 UK pounds I was able to replace the power supply, processor fan and put my hard drive in a accoustic shield. The machine is now so quiet that I've got to check the harddrive LED to make sure that it's working sometimes :). Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot process robustness
This is used successfullly in the thousands of interjets out there in the field. Unfortunatly the new bootblock writers never considered this an important enough feature to emulate. but it gives you a place to look. One of the "new bootblock authors" actually commented on this thread, including some of the reasons why this approach wasn't taken... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
Bingo!
Thanks guys!
Russell
%John Polstra ([EMAIL PROTECTED]) wrote:
% In article [EMAIL PROTECTED],
% Russell L. Carter [EMAIL PROTECTED] wrote:
%
% On a fairly recent -STABLE I am getting this failure:
%
% ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:2033
%
% I assume I'm doing something stupid, however the same code
% works on Linux gcc-2.95.2, so I'm looking for what the
% difference might be.
%
% The program is an ACE/TAO C++ program that dlsym()s an object,
% uses it happily, and then gets the assertion when dlclose()ing
% from the containing object's dtor.
%
% The assertion is that the refcount != 0. What should I
% do to fix that?
%
% There is a bug in the dynamic linker in connection with calling dlopen
% or dlclose from a static constructor or destructor, and this sounds
% like it's related to that. I came up with a fix for it which Peter
% Wemm was testing at Yahoo. That was a few months ago, and I'll have
% to dig it out again after the holiday madness has subsided. If you
% haven't heard from me by Saturday Jan. 6, I'd appreciate a gentle
% reminder to [EMAIL PROTECTED].
%
%Do you mean this patch?
%--- rtld.c 2000/08/01 07:17:54 1.1.1.3
%+++ rtld.c 2000/09/05 22:16:49 1.2
%@@ -694,7 +694,7 @@
% if (obj == (Obj_Entry *) handle)
% break;
%
%-if (obj == NULL || obj-dl_refcount == 0) {
%+if (obj == NULL || obj-refcount == 0 || obj-dl_refcount == 0) {
% _rtld_error("Invalid shared object handle %p", handle);
% return NULL;
% }
%@@ -1994,6 +1994,8 @@
% {
% const Needed_Entry *needed;
%
%+if (root-refcount == 0)
%+ return;
% assert(root-refcount != 0);
% root-refcount--;
% if (root-refcount == 0)
%
%--
%Paul Saab
%Technical Yahoo
[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
%Do You .. uhh .. Yahoo!?
%
%
%To Unsubscribe: send mail to [EMAIL PROTECTED]
%with "unsubscribe freebsd-hackers" in the body of the message
%
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
AMD PM driver finally there!
OK, I've finally got there with the AMD pm/smbus driver. It's now newbus, though this was quite a weird experience. In the end, I found that my BIOS wasn't giving out any I/O resource information for the AMD 756's power management function, hence bus_alloc_resource failed. A bus_set_resource fixed this. So... I'd like it committed, though I don't really know how this process works. The diffs are all available at: http://www.3d-med.cse.dmu.ac.uk/~mcf/amdpm.tar.gz ...if anyone can do the Right Thing with it. Thanks, Matt. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot process robustness
the current ideas all fail badly in the face of 'a' partition filesystem corruption. Very true. I also looked at the CMOS scratchpad registers... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk
Warner Losh writes: The only thing I couldn't figure out how to do was to mount the file. Since I grabbed the disk partition, I wasn't sure I could just use vnconfig since there was no FreeBSD label on that partition. vnconfig -s labels /dev/vn... -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk
:In message [EMAIL PROTECTED] Matthew Jacob :writes: :: Isn't this what the Linux badblocks program is for? Why don't you take that :: and find a way to feed this into badsect(8)... : :I thought the linux badblocks program found bad blocks and keep the :user from using them. I want to read the entire disk and the parts :that don't read I want to try again later to see if I can maybe get :lucky. : :The disk has too many bad sectors to really use... : :So far the brute force approach seems to be going quickly. : :Warner I wrote a little program to 'recover' a bad disk at BEST, but I've lost it. It's simple, though. Just write a program to open up the raw device and read() large (32K) chunks, writing the output to a file. When you get a read() error lseek() back to the beginning of the 32K block and then proceed to read the block using 512 byte reads. If/when you get a read() error reading the smaller block, lseek/retry a couple of times, report the problem, lseek past the bad block, and continue. When you are through you will have an output image sitting in a file that you can then fsck and dd onto a new disk. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Easy way to recover disk (fwd)
:I thought the linux badblocks program found bad blocks and keep the :user from using them. I want to read the entire disk and the parts :that don't read I want to try again later to see if I can maybe get :lucky. The linux program creates a data file which the fsckext program uses to allocate all the bad spots into a single file. For scsi disks you don't have the option of bad block replacement under linux. It's simple, though. Just write a program to open up the raw device and read() large (32K) chunks, writing the output to a file. If you are too lazy to write a program you can use good old 'dd' with the extra options: bs=1024 conv=noerror,sync When you are through you will have an output image sitting in a file that you can then fsck and dd onto a new disk. Unless the bad spot happens to be an indirect or double indirect block. Then you are in for a long night of fsdb'in. One of the things I'd like to see in a file system enhancement would be the implementation of "shadow" indirect blocks much like the extra superblocks that we can use if the primary one gets stomped. Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make(1) -DREMOTE?
On Tue, Dec 26, 2000 at 04:01:33AM -0500, Will Andrews wrote: So, I'm wondering who uses it, and what purpose it serves. There is nothing in the manpage about this "feature". So from general consensus, people who desire this functionality can get it from ports/devel/pmake and the (non-functional) -DREMOTE code can be nuked from make(1). Right? -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
