Re: Strange CAM errors
On 2012-12-18 1:01, Jim Harris wrote: On Mon, Dec 17, 2012 at 4:52 PM, Willem Jan Withagen w...@digiware.nl mailto:w...@digiware.nl wrote: Right, That did the trick. Thanx for the code. --WjW Patch committed as r244369. It will get MFC'd but obviously won't be in 9.1. Oke, thanx very much. As far as I can tell the has not hurt the system, since it seems to be probing code. And probing finds all the disks. There are also some ZFS reboot fixes by Andriy, that will only make it in after the release of 9.1. And that one is really a tricky/nasty one because it makes it easy the hang-up remote systems in the upgrade process. And would definitely deserve a warning in the release notes Since otherwise there might be more than the average set of complaints. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
No more torrents.....
Hi, Not sure on what other list this would be discussed... But I noticed that: Error 503 torrents.FreeBSD.org is offline. It will probably will not be back. And this has been one of the small ways to support the FreeBSD community, by offering almost all images on torrents Got about 750 full 7.0 CD1 download 350 full 7.0 DVD1 downloads So what is the reason for this? policy no more support? --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Startup lapic messages
Hi list, I've installed FreeBSD 9.1R amd64 on a new Intel server. The following lapic messages appear during system startup: lapic18: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic50: Forcing LINT1 to edge trigger SMP: AP CPU #6 Launched! lapic20: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! lapic32: Forcing LINT1 to edge trigger SMP: AP CPU #4 Launched! lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic34: Forcing LINT1 to edge trigger SMP: AP CPU #5 Launched! lapic52: Forcing LINT1 to edge trigger SMP: AP CPU #7 Launched! I've never seen such messages in past. Does it mean I have some hardware problem/misconfiguration? -- Thanks, Serguey. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD-9.0-RELEASE-amd64 fails to start with SMP on qemu-kvm
Hello, When i try to run FreeBSD-9.0-RELEASE-amd on more than 1 vcpu in quemu-kvm (Fedora Core 17) eg. with: qemu-kvm -m 1024m -cpu host -smp 2 -cdrom /storage/iso/FreeBSD-9.0-RELEASE-amd64-dvd1.iso it freezes KVM with: KVM internal error. Suberror: 1 emulation failure RAX=80b0d4c0 RBX=0009f000 RCX=c080 RDX= RSI=d238 RDI= RBP= RSP= R8 = R9 = R10= R11= R12= R13= R14= R15= RIP=0009f076 RFL=00010086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = f300 DPL=3 DS16 [-WA] CS =0008 00209900 DPL=0 CS64 [--A] SS =9f00 0009f000 f300 DPL=3 DS16 [-WA] DS =0018 00c09300 DPL=0 DS [-WA] FS = f300 DPL=3 DS16 [-WA] GS = f300 DPL=3 DS16 [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 0009f080 0020 IDT= CR0=8011 CR2= CR3=0009c000 CR4=0030 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0501 Code=00 00 00 80 0f 22 c0 ea 70 f0 09 00 08 00 48 b8 c0 d4 b0 80 ff ff ff ff ff e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 99 20 00 ff ff 00 00 Freeze occurs immediately after kernel messages: Copyright (c) 1992-2012 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 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (2925.91-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0xf83fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,SS Features2=0x80982201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,HV AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF real memory = 1073741824 (1024 MB) avail memory = 1011343360 (964 MB) Event timer LAPIC quality 400 ACPI APIC Table: BOCHS BXPCAPIC This also applies to FreeBSD-7.3-RELEASE-amd64 and FreeBSD-9.1-RC3-amd64 (other releases not tested). When quemu-kvm is started without SMP (1 vpcu) amd64 FreeBSD kernel boots correctly. I did not notice this problem for the i386 versions (FreeBSD-7.3-RELEASE-i386, FreeBSD-9.0-RELEASE-i386, FreeBSD-9.1-RC3-i386). CPUs on KVM host -- Xeons X5570 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz stepping: 5 microcode : 0x11 cpu MHz : 2926.183 cache size : 8192 KB physical id : 1 siblings: 8 core id : 0 cpu cores : 4 apicid : 16 initial apicid : 16 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 5852.36 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: Any ideas? Regards, Artur Samborski ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD-9.0-RELEASE-amd64 fails to start with SMP on qemu-kvm
Hello, When i try to run FreeBSD-9.0-RELEASE-amd on more than 1 vcpu in quemu-kvm (Fedora Core 17) eg. with: qemu-kvm -m 1024m -cpu host -smp 2 -cdrom /storage/iso/FreeBSD-9.0-RELEASE-amd64-dvd1.iso it freezes KVM with: KVM internal error. Suberror: 1 emulation failure RAX=80b0d4c0 RBX=0009f000 RCX=c080 RDX= RSI=d238 RDI= RBP= RSP= R8 = R9 = R10= R11= R12= R13= R14= R15= RIP=0009f076 RFL=00010086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = f300 DPL=3 DS16 [-WA] CS =0008 00209900 DPL=0 CS64 [--A] SS =9f00 0009f000 f300 DPL=3 DS16 [-WA] DS =0018 00c09300 DPL=0 DS [-WA] FS = f300 DPL=3 DS16 [-WA] GS = f300 DPL=3 DS16 [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS64-busy GDT= 0009f080 0020 IDT= CR0=8011 CR2= CR3=0009c000 CR4=0030 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0501 Code=00 00 00 80 0f 22 c0 ea 70 f0 09 00 08 00 48 b8 c0 d4 b0 80 ff ff ff ff ff e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 99 20 00 ff ff 00 00 Freeze occurs immediately after kernel messages: Copyright (c) 1992-2012 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 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz (2925.91-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0xf83fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,SS Features2=0x80982201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,HV AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF real memory = 1073741824 (1024 MB) avail memory = 1011343360 (964 MB) Event timer LAPIC quality 400 ACPI APIC Table: BOCHS BXPCAPIC This also applies to FreeBSD-7.3-RELEASE-amd64 and FreeBSD-9.1-RC3-amd64 (other releases not tested). When quemu-kvm is started without SMP (1 vpcu) amd64 FreeBSD kernel boots correctly. I did not notice this problem for the i386 versions (FreeBSD-7.3-RELEASE-i386, FreeBSD-9.0-RELEASE-i386, FreeBSD-9.1-RC3-i386). CPUs on KVM host -- Xeons X5570 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz stepping: 5 microcode : 0x11 cpu MHz : 2926.183 cache size : 8192 KB physical id : 1 siblings: 8 core id : 0 cpu cores : 4 apicid : 16 initial apicid : 16 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid bogomips: 5852.36 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: Any ideas? Regards, Artur Samborski ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)
Dear all: Just an FYI that the new distributed audit daemon has been MFC'd to 9-STABLE. As noted in UPDATING, you will need to run mergemaster -p before using installkernel or installworld targets in order to add the new auditdistd system user. This should be part of the regular update cycle anyway, but after the experience of adding auditdistd in 10-CURRENT, we've discovered that many people are skipping that step in the update cycle, so I figured it best to point out here. (Technically, only installworld requires the user, but the user-check guards in the system Makefiles are enforced for both targets.) More details on the daemon below. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:15:11 + (GMT) From: Robert Watson rwat...@freebsd.org To: curr...@freebsd.org Cc: secur...@freebsd.org Subject: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) Dear all: I've now committed the build glue required to install the recently merged Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and sponsored by the FreeBSD Foundation. This allows individual hosts generating audit trails to submit trails to a central audit server for review and safe keeping. Part of the goal is to ensure that a host submitting trail data can't later modify the trails. Pawel uses a variety of useful security- and resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the recent security incident in the FreeBSD.org cluster illustrated, having reliable and detailed audit trails makes a big difference in forensic work, and hopefully this will allow the FreeBSD Project (and our users) to do that better in the future. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:11:46 + (UTC) From: Robert Watson rwat...@freebsd.org To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Subject: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd Author: rwatson Date: Sat Dec 1 15:11:46 2012 New Revision: 243752 URL: http://svnweb.freebsd.org/changeset/base/243752 Log: Merge a number of changes required to hook up OpenBSM 1.2-alpha2's auditdistd (distributed audit daemon) to the build: - Manual cross references - Makefile for auditdistd - rc.d script, rc.conf entrie - New group and user for auditdistd; associated aliases, etc. The audit trail distribution daemon provides reliable, cryptographically protected (and sandboxed) delivery of audit tails from live clients to audit server hosts in order to both allow centralised analysis, and improve resilience in the event of client compromises: clients are not permitted to change trail contents after submission. Submitted by: pjd Sponsored by: The FreeBSD Foundation (auditdistd) Added: head/etc/rc.d/auditdistd (contents, props changed) head/usr.sbin/auditdistd/ head/usr.sbin/auditdistd/Makefile (contents, props changed) Modified: head/etc/defaults/rc.conf head/etc/ftpusers head/etc/mail/aliases head/etc/master.passwd head/etc/mtree/BSD.var.dist head/etc/rc.d/Makefile head/share/man/man4/audit.4 head/usr.sbin/Makefile Modified: head/etc/defaults/rc.conf == --- head/etc/defaults/rc.conf Sat Dec 1 13:46:37 2012(r243751) +++ head/etc/defaults/rc.conf Sat Dec 1 15:11:46 2012(r243752) @@ -590,6 +590,9 @@ sendmail_rebuild_aliases=NO # Run newa auditd_enable=NO # Run the audit daemon. auditd_program=/usr/sbin/auditd# Path to the audit daemon. auditd_flags= # Which options to pass to the audit daemon. +auditdistd_enable=NO # Run the audit daemon. +auditdistd_program=/usr/sbin/auditdistd # Path to the auditdistd daemon. +auditdistd_flags= # Which options to pass to the auditdistd daemon. cron_enable=YES# Run the periodic job daemon. cron_program=/usr/sbin/cron# Which cron executable to run (if enabled). cron_dst=YES # Handle DST transitions intelligently (YES/NO) Modified: head/etc/ftpusers == --- head/etc/ftpusers Sat Dec 1 13:46:37 2012(r243751) +++ head/etc/ftpusers Sat Dec 1 15:11:46 2012(r243752) @@ -19,6 +19,7 @@ _pflogd _dhcp uucp pop +auditdistd www hast nobody Modified: head/etc/mail/aliases == --- head/etc/mail/aliases Sat Dec 1 13:46:37 2012(r243751) +++ head/etc/mail/aliases Sat Dec 1 15:11:46 2012(r243752) @@ -26,6 +26,7
RE: Custom Kernel for FreeBSD Installation
From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Torfinn Ingolfsen Sent: Tuesday, December 11, 2012 4:02 PM Not an answer to your question, but do you need to? Can't the DL380 G3 boot from something else, like a usb image? The issue is with the ciss(4) driver restricting the maximum number of logical drives to 15 in order to limit the driver's memory requirements. If I understand it correctly, the driver allocates a certain amount of memory (under 4 GiB) for each logical drive for DMA. If an adapter exports more than 15 logical drives, the driver refuses to attach any of them and logs an error message like adapter claims to report absurd number of logical drives (20 15). On my server, I have 20 logical drives (20 single-disk RAID-0 arrays), so the driver won't work without modification. So, to close the loop on this, I modified the value of CISS_MAX_LOGICAL in src/sys/dev/ciss/cissvar.h and ran make buildworld buildkernel. I think I had to install sysutils/cdrecord as well. Then, to create an installation CD from the newly built world, I ran cd release; make cdrom -D NOPORTS -D NOSRC -D NODOC. This last step resulted in a file named release.iso in the release directory. I successfully booted the FreeBSD installer using the new image, and FreeBSD was able to detect and attach all 20 logical drives. Leon Kos suggested increasing the value of the CISS_MAX_LOGICAL constant (see http://www.freebsd.org/cgi/query-pr.cgi?pr=151564cat=kern), but I think a boot-time tunable is a better approach. I'm currently testing this out and will submit patches if successful. Best wishes, Matthew -- I FIGHT FOR THE USERS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)
On 12/18/12 16:18, Robert Watson wrote: Dear all: Just an FYI that the new distributed audit daemon has been MFC'd to 9-STABLE. Thanks. As noted in UPDATING, you will need to run mergemaster -p before using installkernel or installworld targets in order to add the new auditdistd system user. This should be part of the regular update cycle anyway, but after the experience of adding auditdistd in 10-CURRENT, we've discovered that many people are skipping that step in the update cycle, so I figured it best to point out here. (Technically, only installworld requires the user, but the user-check guards in the system Makefiles are enforced for both targets.) Maybe /usr/src/UPDATING should be updated? The end of /usr/src/UPDATING mentiones mergemaster -p after the installtion of the new kernel and rebooting to single user mode instead of before. This is on 9.1-RELEASE and also in CURRENT. At least the entry in /usr/src/UPDATING on CURRENT for this change 20121201: With the addition of auditdistd(8), a new auditdistd user is now depended on during installworld. mergemaster -p can be used to add the user prior to installworld, as documented in the handbook. should be prior to installkernel then also instead of prior to installworld More details on the daemon below. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:15:11 + (GMT) From: Robert Watson rwat...@freebsd.org To: curr...@freebsd.org Cc: secur...@freebsd.org Subject: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) Dear all: I've now committed the build glue required to install the recently merged Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and sponsored by the FreeBSD Foundation. This allows individual hosts generating audit trails to submit trails to a central audit server for review and safe keeping. Part of the goal is to ensure that a host submitting trail data can't later modify the trails. Pawel uses a variety of useful security- and resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the recent security incident in the FreeBSD.org cluster illustrated, having reliable and detailed audit trails makes a big difference in forensic work, and hopefully this will allow the FreeBSD Project (and our users) to do that better in the future. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:11:46 + (UTC) From: Robert Watson rwat...@freebsd.org To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Subject: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd Author: rwatson Date: Sat Dec 1 15:11:46 2012 New Revision: 243752 URL: http://svnweb.freebsd.org/changeset/base/243752 Log: Merge a number of changes required to hook up OpenBSM 1.2-alpha2's auditdistd (distributed audit daemon) to the build: - Manual cross references - Makefile for auditdistd - rc.d script, rc.conf entrie - New group and user for auditdistd; associated aliases, etc. The audit trail distribution daemon provides reliable, cryptographically protected (and sandboxed) delivery of audit tails from live clients to audit server hosts in order to both allow centralised analysis, and improve resilience in the event of client compromises: clients are not permitted to change trail contents after submission. Submitted by:pjd Sponsored by:The FreeBSD Foundation (auditdistd) Added: head/etc/rc.d/auditdistd (contents, props changed) head/usr.sbin/auditdistd/ head/usr.sbin/auditdistd/Makefile (contents, props changed) Modified: head/etc/defaults/rc.conf head/etc/ftpusers head/etc/mail/aliases head/etc/master.passwd head/etc/mtree/BSD.var.dist head/etc/rc.d/Makefile head/share/man/man4/audit.4 head/usr.sbin/Makefile Modified: head/etc/defaults/rc.conf == --- head/etc/defaults/rc.confSat Dec 1 13:46:37 2012 (r243751) +++ head/etc/defaults/rc.confSat Dec 1 15:11:46 2012 (r243752) @@ -590,6 +590,9 @@ sendmail_rebuild_aliases=NO# Run newa auditd_enable=NO# Run the audit daemon. auditd_program=/usr/sbin/auditd# Path to the audit daemon. auditd_flags=# Which options to pass to the audit daemon. +auditdistd_enable=NO# Run the audit daemon. +auditdistd_program=/usr/sbin/auditdistd# Path to the auditdistd daemon. +auditdistd_flags=# Which options to pass to the auditdistd daemon. cron_enable=YES# Run the periodic job daemon. cron_program=/usr/sbin/cron# Which cron executable to run (if
Re: MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)
On 12/18/12 16:18, Robert Watson wrote: Dear all: Just an FYI that the new distributed audit daemon has been MFC'd to 9-STABLE. Thanks. As noted in UPDATING, you will need to run mergemaster -p before using installkernel or installworld targets in order to add the new auditdistd system user. This should be part of the regular update cycle anyway, but after the experience of adding auditdistd in 10-CURRENT, we've discovered that many people are skipping that step in the update cycle, so I figured it best to point out here. (Technically, only installworld requires the user, but the user-check guards in the system Makefiles are enforced for both targets.) Maybe /usr/src/UPDATING should be updated? The end of /usr/src/UPDATING mentiones mergemaster -p after the installtion of the new kernel and rebooting to single user mode instead of before. This is on 9.1-RELEASE and also in CURRENT. At least the entry in /usr/src/UPDATING on CURRENT for this change 20121201: With the addition of auditdistd(8), a new auditdistd user is now depended on during installworld. mergemaster -p can be used to add the user prior to installworld, as documented in the handbook. should be prior to installkernel then also instead of prior to installworld Greetings, FWIW, I just performed an build(world||kernel) install(world||kernel) yesterday. I used the following: cd /usr/src make buildworld make buildkernel KERNCONF=mykern_name_here make install KERNCONF=mykern_name_here reboot to single user... mount -u / mount -a cd /usr/src mergemaster -p blah,blah,blah... make installworld mergemaster reboot All of the auditdistd bits were merged into my system, and all is well. Isn't that the way Updating lists the correct order? Anyway, that's how I understood it, and just wanted to report that it all worked as expected/anticipated. HTH, and best wishes. --Chris More details on the daemon below. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:15:11 + (GMT) From: Robert Watson rwat...@freebsd.org To: curr...@freebsd.org Cc: secur...@freebsd.org Subject: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) Dear all: I've now committed the build glue required to install the recently merged Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and sponsored by the FreeBSD Foundation. This allows individual hosts generating audit trails to submit trails to a central audit server for review and safe keeping. Part of the goal is to ensure that a host submitting trail data can't later modify the trails. Pawel uses a variety of useful security- and resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the recent security incident in the FreeBSD.org cluster illustrated, having reliable and detailed audit trails makes a big difference in forensic work, and hopefully this will allow the FreeBSD Project (and our users) to do that better in the future. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:11:46 + (UTC) From: Robert Watson rwat...@freebsd.org To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Subject: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd Author: rwatson Date: Sat Dec 1 15:11:46 2012 New Revision: 243752 URL: http://svnweb.freebsd.org/changeset/base/243752 Log: Merge a number of changes required to hook up OpenBSM 1.2-alpha2's auditdistd (distributed audit daemon) to the build: - Manual cross references - Makefile for auditdistd - rc.d script, rc.conf entrie - New group and user for auditdistd; associated aliases, etc. The audit trail distribution daemon provides reliable, cryptographically protected (and sandboxed) delivery of audit tails from live clients to audit server hosts in order to both allow centralised analysis, and improve resilience in the event of client compromises: clients are not permitted to change trail contents after submission. Submitted by:pjd Sponsored by:The FreeBSD Foundation (auditdistd) Added: head/etc/rc.d/auditdistd (contents, props changed) head/usr.sbin/auditdistd/ head/usr.sbin/auditdistd/Makefile (contents, props changed) Modified: head/etc/defaults/rc.conf head/etc/ftpusers head/etc/mail/aliases head/etc/master.passwd head/etc/mtree/BSD.var.dist head/etc/rc.d/Makefile head/share/man/man4/audit.4 head/usr.sbin/Makefile Modified: head/etc/defaults/rc.conf == ---
Re: MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)
On 12/18/2012 9:18 AM, Robert Watson wrote: Dear all: Just an FYI that the new distributed audit daemon has been MFC'd to 9-STABLE. As noted in UPDATING, you will need to run mergemaster -p before using installkernel or installworld targets in order to add the new auditdistd system user. This should be part of the regular update cycle anyway, but after the experience of adding auditdistd in 10-CURRENT, we've discovered that many people are skipping that step in the update cycle, so I figured it best to point out here. (Technically, only installworld requires the user, but the user-check guards in the system Makefiles are enforced for both targets.) Have you seen misc/174405? Apparently installkernel is requiring the user as well. The documented process in UPDATING does not mention running mergemaster -p before [install]kernel. More details on the daemon below. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:15:11 + (GMT) From: Robert Watson rwat...@freebsd.org To: curr...@freebsd.org Cc: secur...@freebsd.org Subject: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) Dear all: I've now committed the build glue required to install the recently merged Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and sponsored by the FreeBSD Foundation. This allows individual hosts generating audit trails to submit trails to a central audit server for review and safe keeping. Part of the goal is to ensure that a host submitting trail data can't later modify the trails. Pawel uses a variety of useful security- and resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the recent security incident in the FreeBSD.org cluster illustrated, having reliable and detailed audit trails makes a big difference in forensic work, and hopefully this will allow the FreeBSD Project (and our users) to do that better in the future. Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Sat, 1 Dec 2012 15:11:46 + (UTC) From: Robert Watson rwat...@freebsd.org To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-h...@freebsd.org Subject: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd Author: rwatson Date: Sat Dec 1 15:11:46 2012 New Revision: 243752 URL: http://svnweb.freebsd.org/changeset/base/243752 Log: Merge a number of changes required to hook up OpenBSM 1.2-alpha2's auditdistd (distributed audit daemon) to the build: - Manual cross references - Makefile for auditdistd - rc.d script, rc.conf entrie - New group and user for auditdistd; associated aliases, etc. The audit trail distribution daemon provides reliable, cryptographically protected (and sandboxed) delivery of audit tails from live clients to audit server hosts in order to both allow centralised analysis, and improve resilience in the event of client compromises: clients are not permitted to change trail contents after submission. Submitted by:pjd Sponsored by:The FreeBSD Foundation (auditdistd) Added: head/etc/rc.d/auditdistd (contents, props changed) head/usr.sbin/auditdistd/ head/usr.sbin/auditdistd/Makefile (contents, props changed) Modified: head/etc/defaults/rc.conf head/etc/ftpusers head/etc/mail/aliases head/etc/master.passwd head/etc/mtree/BSD.var.dist head/etc/rc.d/Makefile head/share/man/man4/audit.4 head/usr.sbin/Makefile Modified: head/etc/defaults/rc.conf == --- head/etc/defaults/rc.confSat Dec 1 13:46:37 2012(r243751) +++ head/etc/defaults/rc.confSat Dec 1 15:11:46 2012(r243752) @@ -590,6 +590,9 @@ sendmail_rebuild_aliases=NO# Run newa auditd_enable=NO# Run the audit daemon. auditd_program=/usr/sbin/auditd# Path to the audit daemon. auditd_flags=# Which options to pass to the audit daemon. +auditdistd_enable=NO# Run the audit daemon. +auditdistd_program=/usr/sbin/auditdistd# Path to the auditdistd daemon. +auditdistd_flags=# Which options to pass to the auditdistd daemon. cron_enable=YES# Run the periodic job daemon. cron_program=/usr/sbin/cron# Which cron executable to run (if enabled). cron_dst=YES# Handle DST transitions intelligently (YES/NO) Modified: head/etc/ftpusers == --- head/etc/ftpusersSat Dec 1 13:46:37 2012(r243751) +++ head/etc/ftpusersSat Dec 1 15:11:46 2012(r243752) @@ -19,6 +19,7 @@ _pflogd _dhcp uucp
Re: No more torrents.....
On 18 December 2012 03:59, Willem Jan Withagen w...@digiware.nl wrote: So what is the reason for this? The software used to seed the torrents was horribly insecure. This was found *prior* to the security incident. policy no more support? I have been trying to convince re@ and clusteradm@ to produce web seed torrents using the same mirrors we have now. I imagine further progress could be made after the 9.1 release. -- Eitan Adler ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: No more torrents.....
I don't know why it went offline, however if you go to http://www.gotbsd.net/ you can get the latest release, I dont know if this can help you. Greetings. -Mensaje original- From: Willem Jan Withagen Sent: Tuesday, December 18, 2012 2:59 AM To: sta...@freebsd.org Subject: No more torrents. Hi, Not sure on what other list this would be discussed... But I noticed that: Error 503 torrents.FreeBSD.org is offline. It will probably will not be back. And this has been one of the small ways to support the FreeBSD community, by offering almost all images on torrents Got about 750 full 7.0 CD1 download 350 full 7.0 DVD1 downloads So what is the reason for this? policy no more support? --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: No more torrents.....
On 18 Dec 2012 19:44, Eitan Adler li...@eitanadler.com wrote: On 18 December 2012 03:59, Willem Jan Withagen w...@digiware.nl wrote: So what is the reason for this? The software used to seed the torrents was horribly insecure. This was found *prior* to the security incident. What software? Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)
On 12/18/12 18:44, Chris H wrote: On 12/18/12 16:18, Robert Watson wrote: Dear all: Just an FYI that the new distributed audit daemon has been MFC'd to 9 20121201: With the addition of auditdistd(8), a new auditdistd user is now depended on during installworld. mergemaster -p can be used to add the user prior to installworld, as documented in the handbook. should be prior to installkernel then also instead of prior to installworld Greetings, FWIW, I just performed an build(world||kernel) install(world||kernel) yesterday. I used the following: cd /usr/src make buildworld make buildkernel KERNCONF=mykern_name_here make install KERNCONF=mykern_name_here Hi I guess you did make installkernel instead of just make install KERNCONF=mykern_name_here ? I did a day ago on a 9.1-RC3: freebsd-update make buildkernel make installkernel Then got prompted that the auditdistd user did not exist so I had to add it prior to installing the kernel. But this was when going from 9.1-RC3 to 9.1-RELEASE So I copied the bits from a CURRENT machine where everything went fine using the standard buildworld, buildkernel, installkernel, mergemaster -p, installworld, mergemaster procedure So that was not the usual way, but just using freebsd-update and installing a custom kernel. On CURRENT it went al well. Never mind and thanks. reboot to single user... mount -u / mount -a cd /usr/src mergemaster -p blah,blah,blah... make installworld mergemaster reboot All of the auditdistd bits were merged into my system, and all is well. Isn't that the way Updating lists the correct order? Yes it is. I did an unusual combination of binary update and then building and installing a custom kernel. Anyway, that's how I understood it, and just wanted to report that it all worked as expected/anticipated. HTH, and best wishes. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)
On 12/18/12 18:44, Chris H wrote: On 12/18/12 16:18, Robert Watson wrote: Dear all: Just an FYI that the new distributed audit daemon has been MFC'd to 9 20121201: With the addition of auditdistd(8), a new auditdistd user is now depended on during installworld. mergemaster -p can be used to add the user prior to installworld, as documented in the handbook. should be prior to installkernel then also instead of prior to installworld Greetings, FWIW, I just performed an build(world||kernel) install(world||kernel) yesterday. I used the following: cd /usr/src make buildworld make buildkernel KERNCONF=mykern_name_here make install KERNCONF=mykern_name_here Hi I guess you did make installkernel instead of just make install KERNCONF=mykern_name_here ? D'OH! :P Sorry. That _should_ have read: make installkernel KERNCONF=mykern_name_here ^^ Good catch! I can assure you, I _did_ do it correctly, when actually performing the install. :) FWIW Mine was a fresh install from the 9.0 CD1, then a sync src, ports make build(world||kernel); install(kernel||world). Best wishes. --Chris I did a day ago on a 9.1-RC3: freebsd-update make buildkernel make installkernel Then got prompted that the auditdistd user did not exist so I had to add it prior to installing the kernel. But this was when going from 9.1-RC3 to 9.1-RELEASE So I copied the bits from a CURRENT machine where everything went fine using the standard buildworld, buildkernel, installkernel, mergemaster -p, installworld, mergemaster procedure So that was not the usual way, but just using freebsd-update and installing a custom kernel. On CURRENT it went al well. Never mind and thanks. reboot to single user... mount -u / mount -a cd /usr/src mergemaster -p blah,blah,blah... make installworld mergemaster reboot All of the auditdistd bits were merged into my system, and all is well. Isn't that the way Updating lists the correct order? Yes it is. I did an unusual combination of binary update and then building and installing a custom kernel. Anyway, that's how I understood it, and just wanted to report that it all worked as expected/anticipated. HTH, and best wishes. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: No more torrents.....
On Tue, Dec 18, 2012 at 11:52 AM, Chris Rees utis...@gmail.com wrote: On 18 Dec 2012 19:44, Eitan Adler li...@eitanadler.com wrote: On 18 December 2012 03:59, Willem Jan Withagen w...@digiware.nl wrote: So what is the reason for this? The software used to seed the torrents was horribly insecure. This was found *prior* to the security incident. What software? A hybrid of bnbt, xbnbt, xbtt, and something else that I don't recall the name of. We ran the seeders from py-bittornado in curses mode in about 15 screen sessions.. by hand. The tracker/indexer code had an open http connect proxy in it (!). The code was particularly difficult to work with and looked extremely light for defensive programming. (string buffer overflows, the works). The bottom line is the nice indexer / tracker / stats thing we had isn't something I feel we can trust. I do believe we can/should publish trackerless/dht torrent files to go with the release binaries. Perhaps an initial web-seed might work, otherwise we could have a few folks with good ftp connectivity do an initial seed from the ftp files. Another option is a no-frills tracker (eg: no gui). So, the old way: xbnbt + xbtt + bnbt provided a tracker, an index, downloads of the .torrent files. via screen, we ran a farm of py-bittornado (which particpated in utorrent-compatible pex/dht) very high maintenence and magic. New way: www.freebsd.org: provides an index and downloads of the .torrent files if required, a no-frills tracker. as required, run py-bittornado for a week or so, and/or well connected folks preload their clients via ftp. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: No more torrents.....
A hybrid of bnbt, xbnbt, xbtt, and something else that I don't recall the name of. We ran the seeders from py-bittornado in curses mode in about 15 screen sessions.. by hand. The tracker/indexer code had an open http connect proxy in it (!). The code was particularly difficult to work with and looked extremely light for defensive programming. (string buffer overflows, the works). The bottom line is the nice indexer / tracker / stats thing we had isn't something I feel we can trust. I do believe we can/should publish trackerless/dht torrent files to go with the release binaries. Perhaps an initial web-seed might work, otherwise we could have a few folks with good ftp connectivity do an initial seed from the ftp files. I would be very much be willing to assist with seeding if we make dht torrent files available from my nodes located in downtown Los Angeles for west-coast and APAC network presence. as an aside: I have been running libtorrent/rtorrent for a bit and it seems like a pretty decent platform for building on. having said that - I am not a security researcher and would be keen to hear if libtorrent/rotrrent suffers from these similar issues? -pete -- pete wright www.nycbug.org @nomadlogicLA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: No more torrents.....
On Tue, Dec 18, 2012 at 3:19 PM, pete wright nomadlo...@gmail.com wrote: A hybrid of bnbt, xbnbt, xbtt, and something else that I don't recall the name of. We ran the seeders from py-bittornado in curses mode in about 15 screen sessions.. by hand. The tracker/indexer code had an open http connect proxy in it (!). The code was particularly difficult to work with and looked extremely light for defensive programming. (string buffer overflows, the works). The bottom line is the nice indexer / tracker / stats thing we had isn't something I feel we can trust. I do believe we can/should publish trackerless/dht torrent files to go with the release binaries. Perhaps an initial web-seed might work, otherwise we could have a few folks with good ftp connectivity do an initial seed from the ftp files. I would be very much be willing to assist with seeding if we make dht torrent files available from my nodes located in downtown Los Angeles for west-coast and APAC network presence. as an aside: I have been running libtorrent/rtorrent for a bit and it seems like a pretty decent platform for building on. having said that - I am not a security researcher and would be keen to hear if libtorrent/rotrrent suffers from these similar issues? Oh wait, I told a lie. It wasn't py-bittornado we used.. it was rtorrent. Thanks for prompting that. I have no concerns with rtorrent except that it was a curses beastie. It was something we had to manually start up after a machine reboot until we did some evil scripts with screen. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: No more torrents.....
On Tue, Dec 18, 2012 at 3:22 PM, Peter Wemm pe...@wemm.org wrote: On Tue, Dec 18, 2012 at 3:19 PM, pete wright nomadlo...@gmail.com wrote: A hybrid of bnbt, xbnbt, xbtt, and something else that I don't recall the name of. We ran the seeders from py-bittornado in curses mode in about 15 screen sessions.. by hand. The tracker/indexer code had an open http connect proxy in it (!). The code was particularly difficult to work with and looked extremely light for defensive programming. (string buffer overflows, the works). The bottom line is the nice indexer / tracker / stats thing we had isn't something I feel we can trust. I do believe we can/should publish trackerless/dht torrent files to go with the release binaries. Perhaps an initial web-seed might work, otherwise we could have a few folks with good ftp connectivity do an initial seed from the ftp files. I would be very much be willing to assist with seeding if we make dht torrent files available from my nodes located in downtown Los Angeles for west-coast and APAC network presence. as an aside: I have been running libtorrent/rtorrent for a bit and it seems like a pretty decent platform for building on. having said that - I am not a security researcher and would be keen to hear if libtorrent/rotrrent suffers from these similar issues? Oh wait, I told a lie. It wasn't py-bittornado we used.. it was rtorrent. Thanks for prompting that. I have no concerns with rtorrent except that it was a curses beastie. It was something we had to manually start up after a machine reboot until we did some evil scripts with screen. ah ok - understood. well i'll keep an eye on the lists, and if some trackerless torrents become available i'll be sure to contribute my resources to this :) I'd volunteer to help build them but unfortunately my human bandwidth is limited atm. cheers, -pete -- pete wright www.nycbug.org @nomadlogicLA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9-STABLE - NFS - NetAPP:
I'm running a few servers sitting on top of a NetAPP file server … everything runs great, but periodically I'm getting: nfs_getpages: error 13 vm_fault: pager read error, pid 11355 (https) errors on my screen … not always same pid … the annoying part is that it seems to always affect the same jail that is running .. if I shutdown all jails on that physical server, everything shuts down except for that *one* jail, with a ps listing looking like: USER PID %CPU %MEMVSZ RSS TT STAT STARTEDTIME COMMAND root 6670 0.0 0.0 9936 1372 ?? DsJ 3:00AM 0:00.01 newsyslog root 6815 0.0 0.0 9936 1288 ?? DsJ 3:00AM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 8361 0.0 0.1 220740 11400 ?? DsJ 7:33PM 0:01.25 /usr/local/sbin/httpd -DNOHTTPACCEPT www 8364 0.0 0.0 0 0 ?? ZJ7:33PM 0:00.00 defunct www 11866 0.0 0.1 318444 16792 ?? TJ7:36PM 0:00.03 /usr/local/sbin/httpd -DNOHTTPACCEPT www 11872 0.0 0.1 297964 14008 ?? TJ7:36PM 0:00.01 /usr/local/sbin/httpd -DNOHTTPACCEPT www 11873 0.0 0.1 306156 15028 ?? DEJ 7:36PM 0:00.02 /usr/local/sbin/httpd -DNOHTTPACCEPT root 17190 0.0 0.0 9936 1240 ?? DsJ 8:00PM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 24864 0.0 0.0 9936 1392 ?? DsJ 4:00AM 0:00.01 newsyslog root 24910 0.0 0.0 9936 1336 ?? DsJ 4:00AM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 29972 0.0 0.0 9936 1240 ?? DsJ 9:00PM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 34221 0.0 0.0 51480 4332 ?? DsJ 4:47AM 0:00.02 sshd: root@pts/1 (sshd) root 42452 0.0 0.0 9936 1296 ?? DsJ 10:00PM 0:00.01 newsyslog root 42522 0.0 0.0 9936 1240 ?? DsJ 10:00PM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 55179 0.0 0.0 9936 1296 ?? DsJ 11:00PM 0:00.01 newsyslog root 55244 0.0 0.0 9936 1240 ?? DsJ 11:00PM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 67592 0.0 0.0 9936 1336 ?? DsJ 12:00AM 0:00.01 newsyslog root 67762 0.0 0.0 9936 1288 ?? DsJ 12:00AM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 81603 0.0 0.0 9936 1340 ?? DsJ 1:00AM 0:00.01 newsyslog root 81640 0.0 0.0 9936 1284 ?? DsJ 1:00AM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 93792 0.0 0.0 9936 1344 ?? DsJ 2:00AM 0:00.01 newsyslog root 93815 0.0 0.0 9936 1288 ?? DsJ 2:00AM 0:00.01 /usr/sbin/newsyslog -f /usr/local/etc/rotate_logs.cfg root 34228 0.0 0.0 67960 4464 1 Ds+J 4:47AM 0:00.00 sshd: root@pts/1 (sshd) root 38473 0.0 0.0 17556 3272 3 SJ4:53AM 0:00.02 /bin/tcsh root 38475 0.0 0.0 14212 1512 3 R+J 4:53AM 0:00.00 ps aux I can do a 'jexec JID /bin/tcsh' to get into the jail, I can perform ps commands, etc … I just can't get those processes to shutdown … everything within the jail is 'up to date' … updates the userland and ports … I've checked over the NetApp, but everything appears fine, and it only seems to repeatedly affect that one jail, on that same physical server ... I have no ideas on what / how to debug this … thoughts? help? thx ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Fri, Dec 7, 2012 at 12:42 PM, Kimmo Paasiala kpaas...@gmail.com wrote: Hello, I wrote a small patch for /etc/network.subr to add support for ipv6_addrs_IF aliases in rc.conf(5) to match the already existing ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 aliases can be written like: ipv6_addrs_re0=2001:db8::::1/64 2001:db8::::2/64 Only this syntax is supported, it's not possible to use the prefixlen nn syntax in the list. The patch is against a recent 9-STABLE, last changed rev of network.subr on my SVN checkout is r242187. I don't have a CURRENT system to test if it applies to CURRENT as well. The patch can be found attached to a PR I sent: http://www.freebsd.org/cgi/query-pr.cgi?pr=174225 I wrote this patch inspired by a question on the FreeBSD forums: http://forums.freebsd.org/showthread.php?t=36136 Please test and report if it works for you :) Regards, Kimmo Paasiala Hello, Did anyone try my patch? I thought it would be nice to have the ipv6_addrs_IF syntax supported to complement the existing ipv4_addrs_IF alias syntax. -Kimmo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1-RC3 fusefs-encfs problem ( ls: b: Bad file descriptor )
On Thu, Dec 6, 2012 at 3:00 AM, Özkan KIRIK ozkan.ki...@gmail.com wrote: I just installed fusefs-encfs from ports. There is something wrong while mounting the fuse. The output : root@host # kldstat Id Refs AddressSize Name 13 0x8020 13e0d58 kernel 21 0x81812000 a9bb fuse.ko root@host # encfs `pwd`/a `pwd`/b The directory /usr/home/sysadmin/a/ does not exist. Should it be created? (y,n) y The directory /usr/home/sysadmin/b does not exist. Should it be created? (y,n) y Creating new encrypted volume. Please choose from one of the following options: enter x for expert configuration mode, enter p for pre-configured paranoia mode, anything else, or an empty line will select standard mode. ? Standard configuration selected. Configuration finished. The filesystem to be created has the following properties: Filesystem cipher: ssl/aes, version 3:0:2 Filename encoding: nameio/block, version 3:0:1 Key Size: 192 bits Block Size: 1024 bytes Each file contains 8 byte header with unique IV data. Filenames encoded using IV chaining mode. File holes passed through to ciphertext. Now you will need to enter a password for your filesystem. You will need to remember this password, as there is absolutely no recovery mechanism. However, the password can be changed later using encfsctl. New Encfs Password: Verify Encfs Password: root@host # root@host # mount /dev/ada0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/fuse0 on /usr/home/b (fusefs, local, synchronous) root@host # cd b b: Not a directory. root@host # ls b ls: b: Bad file descriptor root@host # umount b umount: b: stat: Bad file descriptor umount: b: unknown file system root@host # umount /usr/home/b - has no errors. I tried this on two different machines with 9.1-RC3 amd64. How can we solve this problem? Sincerely, Ozkan KIRIK I have the same problem. Downgrading sysutils/fusefs-kmod and sysutils/fusefs-libs as described in the PR linked to below allowed me to mount again. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/173240 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
