5.x to 6.x or 7.x with 64MB /
I have a machine which I have recently upgraded using cvsup, from 4.x to RELENG_5, as a staging post en route to 7.x. The upgrade went well until installworld ran out of disk on / and I realised it was only 64BMB. My bad; should have checked before upgrading. With help from an on-site colleague the installworld was nursed to completion. But can I get the same machine up to 6.x or 7.x without repartitioning? Advice please. Partitions are as follows. ad0 2439 M ad0s1 2439 M ad0s1a64 M / ad0s1b 128 M swap ad0s1e 1024 M /var ad0s1f 600 M /home ad0s1g 623 M - ad157259 M ad1s1 57259 M ad0s1a 10240 M /usr It occurs to me that if ad0s1a is insufficient then I could use ad0s1g as swap, and repurpose ad0s1b as a new /. Is it straightforward to installworld/mergemaster to somewhere other than / ? Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog console log not logging SCSI problems
At 2008-05-20 16:21:01+, Oliver Fromme writes: Nick Barnes wrote: One of our FreeBSD boxes has a SCSI controller and disk, which showed problems earlier this week. There was a lot of of chatter from the SCSI driver in /var/log/messages and to the console. However, the console is unattended and we only discovered the problem subsequently because /var/log/console.log didn't show any of the chatter. The console.* syslog facility only logs real console output, i.e. things written to /dev/console. That does _not_ include output from the kernel. For logging kernel output you have to use the kern.* syslog facility. OK. So when syslogd directs output to the console, it does not also treat it as console.* output? Thanks for this explanation. I'll modify my syslog.conf accordingly. Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syslog console log not logging SCSI problems
At 2008-05-15 10:02:03+, Jeremy Chadwick writes: Another thing I can think of would be your kernel configuration. Can you provide it? Just GENERIC. By the way, the need to set kern.maxdsiz - for really big processes - doesn't seem to be documented anywhere. I could have sworn it used to be in the Handbook, but I don't see it there. I guess it should be both there and in tuning(7). Rediscovering this switch took me 30 minutes yesterday. Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
syslog console log not logging SCSI problems
One of our FreeBSD boxes has a SCSI controller and disk, which showed problems earlier this week. There was a lot of of chatter from the SCSI driver in /var/log/messages and to the console. However, the console is unattended and we only discovered the problem subsequently because /var/log/console.log didn't show any of the chatter. console.log is otherwise working, and very helpful (e.g. it shows /etc/rc output at boot which lets us spot daemon failures). We've rebuilt the machine now (fan failure leading to boot disk failure), so I can't report the SCSI chatter in question, but here is the dmesg and syslog.conf. Any suggestions? (yes, I know this is 6.2-RELEASE; I'm partway through cvsupping; the failure was under 6.2p11). Thanks in advance, Nick Barnes dmesg: Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3006.01-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf4a Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x649dSSE3,RSVD2,MON,DS_CPL,EST,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Logical CPUs per core: 2 real memory = 2137440256 (2038 MB) avail memory = 2086498304 (1989 MB) ACPI APIC Table: INTEL D945GTP FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: INTEL D945GTP on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 cpu1: ACPI CPU on acpi0 acpi_perf1: ACPI CPU Frequency Control on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_perf1: ACPI CPU Frequency Control on cpu1 acpi_perf1: failed in PERF_STATUS attach device_attach: acpi_perf1 attach returned 6 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: display, VGA at device 2.0 (no driver attached) pci0: multimedia at device 27.0 (no driver attached) pcib1: ACPI PCI-PCI bridge at device 28.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 28.2 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 28.3 on pci0 pci3: ACPI PCI bus on pcib3 uhci0: UHCI (generic) USB controller port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: UHCI (generic) USB controller port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: UHCI (generic) USB controller port 0x2020-0x203f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: UHCI (generic) USB controller on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801GB/R (ICH7) USB 2.0 controller mem 0x901c4000-0x901c43ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib4 ahc0: Adaptec 29160 Ultra160 SCSI adapter port 0x1000-0x10ff mem 0x9000-0x9fff irq 21 at device 0.0 on pci4 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs fxp0
Re: syslog console log not logging SCSI problems
At 2008-05-15 09:46:32+, Jeremy Chadwick writes: On Thu, May 15, 2008 at 10:14:01AM +0100, Nick Barnes wrote: One of our FreeBSD boxes has a SCSI controller and disk, which showed problems earlier this week. There was a lot of of chatter from the SCSI driver in /var/log/messages and to the console. However, the console is unattended and we only discovered the problem subsequently because /var/log/console.log didn't show any of the chatter. console.log is otherwise working, and very helpful (e.g. it shows /etc/rc output at boot which lets us spot daemon failures). We've rebuilt the machine now (fan failure leading to boot disk failure), so I can't report the SCSI chatter in question, but here is the dmesg and syslog.conf. Any suggestions? /boot/loader.conf, /boot.config, and /etc/make.conf would also be useful. All empty, except setting kern.maxdsiz in /boot/loader.conf. Running GENERIC. If this happens again, I will retain a copy of /var/log/messages so I can report the SCSI messages in question, but they aren't as interesting to me as the fact that they didn't appear in console.log. Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: $HOME changed from 6.2 to 6.3 and 7.0 ?!
At 2008-02-29 12:15:26+, Willy Offermans writes: Is /usr/local/etc/periodic/daily/ not the place to put your daily executable scripts? What is daily.local about? /etc/daily.local predates /etc/periodic/, somewhat. It was introduced in 1996. Before that, there was just the /etc/daily script, which was cut over to /etc/periodic/... some time in 1997. God bless the FreeBSD project's careful approach to compatibility. Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Failing to understand getrusage()
At 2006-03-02 22:24:17+, Nik Clayton writes:
I'm failing to understand how getrusage() works, which is a bit perplexing,
because it doesn't seem like it would be terribly complicated.
ru_maxrss is the maximum resident set size, not the heap size.
malloc(big) doesn't grow the resident set. Touching the memory you
have allocated will grow the resident set. Try this:
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
p = malloc(SIZE);
assert(p)
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
for (i=0; iSIZE; ++i) {
p[i] = 0;
}
getrusage(RUSAGE_SELF, ru);
printf(%lu\n, ru.ru_maxrss);
Nick B
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop choices
At 2005-11-29 10:19:17+, Greg 'groggy' Lehey writes: On Thursday, 24 November 2005 at 11:17:41 -0500, [EMAIL PROTECTED] wrote: On the [Dell] warrenty... I'm hard on equipment and I depend on my equipment. I've been impressed that if I put my foot down and say that I believe something needs replacing, then without much fuss, they do it. The next day onsite service is cool. You obviously have better experience than I do. My Inspiron 6000 was apparently used: it arrived without the usual plastic coating on the lid, with scratches which couldn't have come from transport instead. Also the ejector for the PC Card fell apart shortly after I got it. It took them over 3 weeks to get a replacement lid to me, by which time I had left for Europe. By the time I get home I will have had the machine for 6 weeks, too long to return it, and only then will I be able to fight the Dell service department about the ejector. Only some time after then will they be able to replace the lid. Yeah. The next day on-site service for my wife's Dell took *two weeks* to arrive (and replace the motherboard, which we had diagnosed as the source of the fault after about 10 minutes). Never again. iBook on order. Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine Replication
At 2005-07-21 19:20:34+, Eli K. Breen writes: All, Does anyone have a good handle on how to replicate (read: image) a freebsd machine from one machine to an ostensibly similar machine? So far I've used countless variations and combinations of the following: dd(Slow, not usefull if the hardware isn't identical?) I have used dd | gzip -9 on many occasions. I don't find it especially slow (it will run at full disk bandwidth, typically 50 MB/sec on current ATA desktop disks, i.e. 3G/minute), and if you want an actual bit-for-bit identical replication then it's the only way to go. It's also very handy for keeping multi-boot slice images around (e.g. images of Windows partitions in various states, for testing purposes). The compressed images often end up nice and small. The disadvantage you may have is that your slice table and/or partition table will be wrong if your target machine has a larger disk. This is pretty easy to fix after the fact with a script using disklabel and/or fdisk. You will get better compression if you dd /dev/zero to your source machine before the initial installation, so that empty sectors are all zeroes. One day I will write a program which zeroes empty blocks of an unmounted filesystem tar (Doesn't replicate MBR) rsync (No MBR support) Replicating the MBR is exceptionally easy with dd: it's the first sector of the disk. Note that this first sector also includes the slice table. You could easily use dd in combination with tar and rsync. Norton Ghost (Doesn't support UFS/UFS2?) G4U (little experience with this) I notice that 'dump' is not in your list. Why is that? Nick Barnes Ravenbrook Limited ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
virtual machines
I run FreeBSD as my main desktop, but occasionally have to develop, build, or test software on a variety of other x86 operating systems (mainly Windows NT 4, Windows XP Pro, and Red Hat Linux). At the moment I have a row of mini-towers and a KVM switch. I'd much rather run these other machines as virtual machines under FreeBSD. Can anyone recommend virtualizing software for FreeBSD? I don't mind having to pay, as long as it really works. I see that VMWare, for instance, is not supported on FreeBSD. I'm running 4.9-RELENG at the moment, but considering an upgrade to 5.x. Nick Barnes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel killing processes when out of swap
At 2005-04-12 13:52:59+, Vivek Khera writes: of swap? Which leads to the question would it not be more sensible to kill off the largest process first as its more than likely that it is responsible for the problem? so when this largest process is your production database server for your e-commerce site, what will you change your recommendation to be? basically, there is no right choice of process to kill. a machine that is out of resources is just a bad situation, and the right thing is to try to avoid getting there with careful monitoring and planning. The right choice is for mmap() to return ENOMEM, and then for malloc() to return NULL, but almost no operating systems make this choice any more. Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel killing processes when out of swap
At 2005-04-12 14:26:40+, Marc Olzheim writes: On Tue, Apr 12, 2005 at 03:06:41PM +0100, Nick Barnes wrote: The right choice is for mmap() to return ENOMEM, and then for malloc() to return NULL, but almost no operating systems make this choice any more. No, the problem occurs only when previously allocated / mmap()d blocks are actually used (written) and when the total of virtual memory has been overcommitted: Physical pages are not allocated to processes at malloc() time, but at time of first usage (Copy On Write). Yes, implicit in my statement is that the OS shouldn't overcommit. I remember when overcommit was new (maybe 1990), and some Unix (Irix, perhaps, or AIX?) made it switchable. There was a bit of flurry in the OS community, as some people (myself included) felt that the OS shouldn't make promises it couldn't fulfill, and that this kill a random process behaviour was more of a bug than a solution. Consider a parallel design which allows (say) file descriptors to be overcommitted. You can open a billion files, but if you touch one of them, that consumes a finite kernel resource, and if the kernel has run out then a randomly chosen process gets killed. Great. many programs have been programmed in a way that assumes this behaviour, for instance by sparsely using large allocations instead of adding the possible extra bookkeeping to allow for smaller allocations. This is the well-known problem with my fantasy world in which the OS doesn't overcommit any resources. All those programs are broken, but it's too costly to fix them. If overcommit had been resisted more effectively in the first place, those programs would have been written properly. My recollection, quite possibly faulty, is that FreeBSD came quite late to the overcommit binge party. Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel killing processes when out of swap
At 2005-04-12 18:17:32+, Matthias Buelow writes: This stuff has been discussed in the past. Indeed. For a couple of examples from the days before BSD systems got overcommit, see these threads from 1990 and 1991: http://groups-beta.google.com/group/comp.unix.aix/browse_frm/thread/91541dbf6b658465/4c590978f1001507?q=overcommitrnum=14#4c590978f1001507 http://groups-beta.google.com/group/comp.unix.aix/browse_frm/thread/38c9bb9996d30eb1/e8c30f78c44a3f62?q=overcommitrnum=12#e8c30f78c44a3f62 Nick B ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to `memset'
At 2005-03-24 08:31:14+, Bruce Evans writes: what is gcc to do when -fno-builtin tells it to turn off its builtins and -ffreestanding tells it that the relevant interfaces might not exist in the library? Plainly, GCC should generate code which fills the array with zeroes. It's not obliged to generate code which calls memset (either builtin or in a library). If it knows that it can do so, then fine. Otherwise it must do it the Old Fashioned Way. So this is surely a bug in GCC. Nick B, who used to write compilers for a living ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC card problems....
At 2005-01-24 00:00:32+, Net Virtual Mailing Lists writes: Hello Stefan (and everyone else!), Thank you for your great comments! I think I have a 3c9xx card around here somewhere, I will give that a shot when it reboots the next time (just to see). It looks like for future systems I'll standardize on the Intel fxp-based cards, I really appreciate that advice! A last piece of advice: get real EtherExpress cards. A number of Intel motherboards come with onboard Ethernet interfaces (maybe they all do now), which the fxp driver understands, but the performance of such interfaces is reputed to be much lower. Nick Barnes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.x can't read 5.x dump?
At 2004-12-02 02:40:53+, Ken Smith writes: On Thu, Dec 02, 2004 at 10:48:43AM +1000, Joel Hatton wrote: I'm backing up a 5.x machine at the moment with this command: dump -0Lau -b128 -f - /var | gzip -2 | ssh FreeBSD4 dd of=aacd0s1f.gz After the dump finishes, I try to read the file on the 4.x destination: # gzip -dc aacd0s1a.gz | restore -ivf - Verify tape and initialize maps Tape is not a dump tape I can scp the file back to the 5.x machine and it loads just fine, so what gives? This type of failure is somewhat scary for me right now, given that I may have to restore files to another destination that may not be 5.x based. This is, unfortunately, something that you should not expect to work for any *nix variant. There's no theoretical reason why the formats used by dump and restore shouldn't be forward and backward compatible, allowing an older restore (to an older filesystem type) to pick out the parts of the dump which make sense to it while ignoring parts which it doesn't understand. But they aren't, so it can't, so you're out of luck. [In theory, the filesystem could package itself, so an old restore binary running on a newer filesystem and given a newer dump would DTRT]. Bikeshed, bikeshed. Nick B ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: port make index (was: Re: make -j$n buildworld : use of -j investigated)
On Thu, 25 Nov 2004 16:19:02 +0900, Rob [EMAIL PROTECTED] wrote: time(minutes) * speed(MHz) * nproc / 1000 MHz Looking at your examples, it seems you divide by 1e5, not by 1000. In other words, buildworld is CPU bound and takes about 6e12 clock cycles. Use -jnproc. Nick B ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
telnet SRA secure login fails intermittently
When I telnet into a FreeBSD box, I get this: $ telnet spong Trying 192.168.0.1... Connected to spong.my.domain Escape character is '^]'. Trying SRA secure login: User (nb): user Password: password If I mistype the password, I get this: [ SRA login failed ] User (nb): user Password: password And so on. Fair enough. But it has seemed to me that I have been mistyping my passwords much more often since about 4.1: maybe 20% of the time, as if somehow telnetd (or SRA, whatever that is) is getting the password check wrong intermittently. And If I fail a login the first time, it seems harder to pass it the second time (the ~20% failure rate goes up to maybe 50%). Recently I have run some little checks on this. Whenever I'm telnetting in from an xterm, if the first login fails, I type my password into another X app (so I can visually check it) and paste it from ther. Sometimes that login does also fail. So there's something wrong somewhere: xterm, telnetd, SRA (?). Unless this is a security feature?? Nick B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: telnet SRA secure login fails intermittently
At 2002-07-29 09:21:25+, Nick Barnes writes: When I telnet into a FreeBSD box, I get this: $ telnet spong Trying 192.168.0.1... Connected to spong.my.domain Escape character is '^]'. Trying SRA secure login: User (nb): user Password: password If I mistype the password, I get this: [ SRA login failed ] User (nb): user Password: password And so on. Fair enough. But it has seemed to me that I have been mistyping my passwords much more often since about 4.1: maybe 20% of the time, as if somehow telnetd (or SRA, whatever that is) is getting the password check wrong intermittently. And If I fail a login the first time, it seems harder to pass it the second time (the ~20% failure rate goes up to maybe 50%). Recently I have run some little checks on this. Whenever I'm telnetting in from an xterm, if the first login fails, I type my password into another X app (so I can visually check it) and paste it from ther. Sometimes that login does also fail. So there's something wrong somewhere: xterm, telnetd, SRA (?). Here's an example, directly cut-and-paste from an emacs buffer, anonymized with search-and-replace. This login succeeds twice and fails on the third attempt: $ telnet test.machine Trying 10.0.0.1... Connected to test.machine. Escape character is '^]'. Trying SRA secure login: User (nb): testuser Password: testpasswd [ SRA accepts you ] FreeBSD/i386 (test.machine) (ttyp1) Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6-RELEASE-p2 (TEST-2002-07-09) #1: Mon Jul 15 13:51:37 GMT 2002 You have mail. $ ^D Connection closed by foreign host. $ telnet test.machine Trying 10.0.0.1... Connected to test.machine. Escape character is '^]'. Trying SRA secure login: User (nb): testuser Password: testpasswd [ SRA accepts you ] FreeBSD/i386 (test.machine) (ttyp1) Last login: Mon Jul 29 10:44:08 from 10.0.0.2 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6-RELEASE-p2 (TEST-2002-07-09) #1: Mon Jul 15 13:51:37 GMT 2002 You have mail. $ ^D Connection closed by foreign host. $ telnet test.machine Trying 193.82.131.17... Connected to test.machine. Escape character is '^]'. Trying SRA secure login: User (nb): testuser Password: testpasswd [ SRA login failed ] User (nb): Nick B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ha!
This is a Google Special Search page. They have 5 of them: http://www.google.com/bsd http://www.google.com/linux http://www.google.com/mac http://www.google.com/microsoft http://www.google.com/unclesam See http://www.google.com/options/index.html Nick Barnes Ravenbrook Limited At 2002-03-15 16:27:25+, Jesse Geddis writes: yea, they got a MS one too and some university ones, but the BSD one was the only good one =) works too lol. they seem to be a linux shop unfortunately. someone needs to go to work on them methinks. -Original Message- From: Chad Leigh -- Shire.Net LLC [mailto:[EMAIL PROTECTED]] Sent: Friday, March 15, 2002 8:21 AM To: [EMAIL PROTECTED] Cc: FreeBSD-STABLE Subject: Re: ha! On Friday, March 15, 2002, at 11:20 , Jesse Geddis wrote: Never knew google had this, lol. I love that little Daemon =) http://www.google.com/bsd Interesting.They also have http://www.google.com/linux http://www.google.com/mac I wonder hopw many more of these there are. Chad _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Upgrading from 3.3 to RELENG_4_4
I'm trying to use cvsup to upgrade from 3.3-RELEASE to RELENG_4_4. My make buildworld has hit the xinstall/strtofflags problem reported many times on this list. So I am following the recommendation given by a few users that I go to RELENG_4_1_1_RELEASE first. This doesn't seem unreasonable, but it would be good if UPDATING told me I had to do this (maybe under To update from 3.x to 4.x stable). Nick Barnes Ravenbrook Limited To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Upgrading from 3.3 to RELENG_4_4
3.3-RELEASE to RELENG_4_1_1_RELEASE failed due to absence of mkstemps. On further archive trawling I see I should go to RELENG_3 first. Sigh. Nick Barnes Ravenbrook Limited At 2001-11-01 16:35:28+, Nick Barnes writes: I'm trying to use cvsup to upgrade from 3.3-RELEASE to RELENG_4_4. My make buildworld has hit the xinstall/strtofflags problem reported many times on this list. So I am following the recommendation given by a few users that I go to RELENG_4_1_1_RELEASE first. This doesn't seem unreasonable, but it would be good if UPDATING told me I had to do this (maybe under To update from 3.x to 4.x stable). Nick Barnes Ravenbrook Limited To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: sshd: requiring password _and_ RSA authentication
At 2001-10-03 18:09:06+, Zvezdan Petkovic writes: On Wed, Oct 03, 2001 at 04:43:39PM +0100, Nick Barnes wrote: One of our servers used to run FreeBSD 2.2.8 with SSH 2 built from /usr/ports/security/ssh2. I'm not sure exactly which version of SSH this was. We had sshd configured to require both a password and RSA (or maybe DSA) authentication. I'm not sure that it checked both. I think that the first authentication method that succeeds lets you through. You probably had password set up as the first method to try. No, it definitely did check both. I recall testing it. I think it was SSH, rather than OpenSSH. This man page suggests that I was using the RequiredAuthentications configuration option: http://www.ssh.com/support/ssh/man/sshd2_config-man.html Only if you set up RSA keys _without_ a passphrase. I never do that. Thanks; I'll make sure our users are using passphrases. This seems like a good solution. Nick B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: probably remote exploit
And you need to be sure that you really _are_ booting off the CD, not booting a hacked kernel from the hard disk which detects that you have a bootable CD in the drive and assumes that you're trying to boot off CD to clean up your system, so _pretends_ to be booting off the CD except when you come to run the checksum utility on the CD. Etc etc. And, of course, if it's a CD-RW, this evil kernel module could just virally infect it :-) Note that one might often want to config a machine so it won't boot from removable media (so that random idiots with access to the front panel can't boot some other OS from CD or floppy), so this scenario isn't _totally_ nuts (only, say, 99.98% nuts). A hassled sysadmin might well put in a CD and reboot without watching too closely, forgetting that the BIOS config will cause the CD to be disregarded. Nick Barnes At 2001-07-23 14:01:40+, Jason Andresen writes: Mike Hoskins wrote: On Fri, 20 Jul 2001, Tom wrote: But if a backdoor is installed, you can't trust cvsup, or make either. Any binary could have been tampered with. For instance, I would make a backdoor make that would detect that an installworld is underway, and always make sure that a backdoored copy of of login and another copy of make. What? Everyone can't just do a quick check against the saved tripwire checksums on CD-R? ;) Seriously. While checksuming an entire system can be impractical, keeping checksums for a barebones set of administrative tools can be a lifesaver. You need to boot off of the CDROM first, otherwise you might have an evil kernel module loaded that can send bogus data to your checksummer when it reads from the disk. It's not quite as easy as just mounting the CD and running the checksums. -- \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] |\/ | ||/ _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
serial console
I have received several individual replies to this message, asking for more details of setting up a serial console. I haven't actually done this myself since 2.2.5 (or maybe 2.2.8), and the procedure has changed a little since then. I refer people to the relevant section of the handbook: URL: http://www.freebsd.org/doc/en_US.ISO_8859-1/books/handbook/serialconsole-setup.html It's easy, and I strongly recommend it for remote FreeBSD machines, assuming you can get at least _some_ other hardware colocated. For instance, you can get a terminal server: a little black box which converts a number of serial lines into TCP/IP connections. That lets you drive serial console for a number of boxes at once, without having to remember that console on foo is cuaa0 on bar, etc. I have used a 16-port Digiboard Portserver (now gathering dust) for this purpose in the past. It goes without saying that you should choose good-quality kit for remote located machines. For instance, don't use anything which doesn't come up reliably first time from a power cycle. Nick B From: Nick Barnes [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: Running Stable on remote production server Date: Mon, 14 May 2001 09:48:46 +0100 Message-ID: [EMAIL PROTECTED] If you have more than one machine at the same remote site, then I recommend setting up each as the serial console for the other. That way you can go single-user, drive fsck, etc etc. Nick B At 2001-05-13 20:36:40+, Juha Saarinen writes: On Sun, 13 May 2001, Mike Smith wrote: It's entirely unnecessary to go single-user when updating a machine; just rebuild the world, optionally run mergemaster, and reboot. Exceptions to this rule do occur, but they're *extremely* rare. Having rebuilt a number of machines remotely in the last couple of weeks, I have to concur... The most important thing is to pay attention to mergemaster, PLUS doing a final check of vital rc and other conf files in /etc BEFORE rebooting. On one site I had the local admin unplug the network cable after the box was shifted into the server room -- I was trying to figure out what I had done wrong until it occured to me to ask if the system was connected to the LAN. His answer was priceless... why do you have to have a network connection? Can't you get at the box remotely? ;-D -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: VPN, via pppd over ssh
At 2001-04-16 20:17:48+, Tom writes: On Mon, 16 Apr 2001, Rich Morin wrote: ... The client suggests that I set up my FreeBSD box to run pppd over ssh, achieving a VPN connection, then let the server act as a router for my That won't likely work too well. When packets are dropped, recovery can occur at the ssh TCP level, and the TCP session encapsulated in ssh. I run PPP over SSH all the time, and it works great. I've never run PPPD. Nick B To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cvsup confusion
At 2001-02-22 17:41:51+, Allen Landsidel writes: I guess we can all be grateful that a great number of people apparently don't bother updating their systems. ;) Yes, and so can they. Many (most?) users are very happy with the FreeBSD they are running, in a headless box stuffed behind a desk somewhere, that has stayed up continuously for the last year or two and never needs more than cursory maintenance. Our main server is running 3.4-RELEASE, and I have two boxes at 2.2.8-RELEASE, upgraded from 2.2.2 a couple of years ago because I had never done an upgrade and wanted to see what the process was like. I have a friend who is still running 2.0.5 (I think), and is still happy with it. It's easy to forget, here in the dizzy heights of -STABLE and -CURRENT, that many, many machines _never_ have an OS upgrade. I would guess that it's the great majority. I bet 99% of all users leave their crontab entries for the periodic scripts unchanged. So regardless of their time zone, they are running a 1 minute after some given hour (0301 in their local time zone). That's 24 possible starting times each day, instead of 1440. Many of the mirrors which are never saturated currently would become saturated at least several times a day under that scheme. You could have a script which adds a randomly-timed line to /etc/crontab. Something involving `jot -r 1 0 59` and `jot -r 1 0 23`. :-) Nick B -- FreeBSD 4.2-STABLE: up 10 days, 20:58 last reboot Mon Feb 12 13:28 (upgraded to FreeBSD 4.2-STABLE) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
