Re: GOST in OPENSSL_BASE
On Mon, Jul 11, 2016, at 05:29, Slawa Olhovchenkov wrote: > > I.e. GOST will be available in openssl. > Under BSD-like license. > Can be this engine import in base system and enabled at time 1.1.0? > And can be GOST enabled now? > I think the wrong question is being asked here. Instead we need to focus on decoupling openssl from base so this can all be handled by ports. -- Mark Felder f...@feld.me ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Issues to maybe prioritize before pkg-base
On Tue, Jul 5, 2016, at 13:01, Jeffrey Bouquet wrote: > Main disk would not boot cleanly. > could not fsck_ffs, cannot find inode > files went missing from /etc (make.conf, pf.conf, firewall*, > file went missing from rc.d > files went missing from /etc/X11 > shell history file remained locked. > find suddenly could not find /usr/local/lib/*/libc.so.5 > freecolor could not find its libraries > Xorg could not find lib* in /usr/local/lib > > > etc > somewhat fixed those from backup. > Which hosed the latest pkg install * upgrades (byobu bump, etc) which I > reinstalled > Put the disk on backup, latter mountroot, ran fsck_ffs on the failing > disk /root and /usr, multiple times, > .. > Inexplicably got all libraries back, working, and files restored AS FAR > AS I KNOW > but as usual in this case, which happens at least twice a year, although > I restore > the desktop and programs (usually) to a working state, with adequate > backups, Are you getting UFS corruption and have SU+J enabled? You might want to turn off SU+J and just use SU. That's probably the issue. -- Mark Felder ports-secteam member f...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ALPHA3 panic with ipfw+dummynet and gif/gre tunnels
Hello, I can pretty reliably panic CURRENT by creating/destroying gif and gre interfaces used for IPv6 tunnels. I'm uploading the dump, kernel.debug, and kernel in a tarball here: https://feld.me/freebsd/crash/r301929.tgz It's still uploading so you might end up with an incomplete download if you fetch it now. Here's the sha256 of it: 1e9fddad1da3bac2b11c51a18c7dad48eb9259acf844f35f5eb40630ca84de64 r301929.tgz Here's the backtrace: (kgdb) bt #0 doadump (textdump=0) at pcpu.h:221 #1 0x80391fab in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0x80391da9 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:440 #3 0x80391b04 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0x80394a3b in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #5 0x80a88913 in kdb_trap (type=, code=, tf=) at /usr/src/sys/kern/subr_kdb.c:654 #6 0x80eb8331 in trap_fatal (frame=0xfe0122831770, eva=26) at /usr/src/sys/amd64/amd64/trap.c:836 #7 0x80eb857d in trap_pfault (frame=0xfe0122831770, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:691 #8 0x80eb7a64 in trap (frame=0xfe0122831770) at /usr/src/sys/amd64/amd64/trap.c:442 #9 0x80e97f91 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #10 0x80c57ebc in ip6_output (m0=, opt=, ro=, flags=, im6o=0x0, ifpp=0x0, inp=) at /usr/src/sys/netinet6/ip6_output.c:1060 #11 0x82661fd2 in dummynet_send (m=) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800 #12 0x82661890 in dummynet_task (context=, pending=) at /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746 #13 0x80a9a1ac in taskqueue_run_locked (queue=) at /usr/src/sys/kern/subr_taskqueue.c:465 #14 0x80a9acf8 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:719 #15 0x80a0b3e4 in fork_exit (callout=0x80a9ac70 , arg=0x8266c8a8, frame=0xfe0122831c00) at /usr/src/sys/kern/kern_fork.c:1038 #16 0x80e984ce in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611 #17 0x in ?? () Current language: auto; currently minimal -- Mark Felder ports-secteam member f...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RPC request sent to 127.0.0.1 becomes from other IP on machine
On Thu, Dec 10, 2015, at 07:37, Rick Macklem wrote: > Hi, > > Mark has reported a problem via email where the nfsuserd daemon sees > requests coming from an IP# assigned to the machine instead of 127.0.0.1. > Here's a snippet from his message: > Ok, I have Plex in a jail and when I scan the remote NFS file share the > *local* server's nfsuserd spams the logs. > Spamming the logs refers to the messages nfsuserd generates when it gets > a request from an address other than 127.0.0.1. > > I think the best solution is to switch nfsuserd over to using an AF_LOCAL > socket like the gssd uses, but that will take a little coding and > probably > won't be MFCable. > > I've sent him the attached patch to try as a workaround. > > Does anyone happen to know under what circumstances the address 127.0.0.1 > gets replaced? > > And do you know if it will always be replaced with the same > address? > (I'm basically wondering if the workaround needs to be a list of IP > addresses > instead of a single address?) > > Thanks in advance for any help with this, rick > I've opened a PR per your request https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205193 -- Mark Felder ports-secteam member f...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenSSH HPN
On Tue, Nov 10, 2015, at 05:25, Willem Jan Withagen wrote:
> On 10-11-2015 12:11, Dag-Erling Smørgrav wrote:
> > Willem Jan Withagen <w...@digiware.nl> writes:
> >> Digging in my logfiles , and its things like:
> >> sshd[84942]: Disconnecting: Too many authentication failures [preauth]
> >>
> >> So errors/warnings without IP-nr.
> >>
> >> And I think I fixed it on one server to also write:
> >> error: maximum authentication attempts exceeded for root from
> >> 173.254.203.88 port 1042 ssh2 [preauth]
> >
> > fail2ban should catch both of these since sshd will print a message for
> > each failed authentication attempt before it prints a message about
> > reaching the limit.
>
> It's already too long to remember the full facts, but when I was looking
> at the parser in sshguard, I think I noticed that certain accesses
> weren't logged and added some more logging rules to catch those.
>
> What I still have lingering is this snippet:
> Index: crypto/openssh/packet.c
> ===
> --- crypto/openssh/packet.c (revision 289060)
> +++ crypto/openssh/packet.c (working copy)
> @@ -1128,8 +1128,10 @@
> logit("Connection closed by %.200s",
> get_remote_ipaddr());
> cleanup_exit(255);
> }
> - if (len < 0)
> + if (len < 0) {
> + logit("Read from socket failed: %.200s",
> get_remote_ipaddr());
> fatal("Read from socket failed: %.100s",
> strerror(errno));
> + }
> /* Append it to the buffer. */
> packet_process_incoming(buf, len);
> }
>
> But like I said: The code I found at openssh was so totally different
> that I did not continued this track, but chose to start running openssh
> from ports. Which does not generate warnings I have questions about the
> originating ip-nr.
>
> >> Are they still willing to accept changes to the old version that is
> >> currently in base?
> >
> > No, why would they do that?
>
> Exactly my question
> I guess I misinterpreted your suggestion on upstreaming patches.
>
> --WjW
>
I honestly think everyone would be better served by porting blacklistd
from NetBSD than trying to increase verbosity for log files.
--
Mark Felder
ports-secteam member
f...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IPFW panic on boot
On Tue, Nov 3, 2015, at 21:29, David Wolfskill wrote: > On Tue, Nov 03, 2015 at 09:08:28PM -0600, Mark Felder wrote: > > Recent ipfw commits now cause my firewall to panic on boot. I had to > > revert them and only pull in Adrian's ath fix which was to fix yet a > > different panic I was encountering... :-) > > > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe01226a33e0 > > vpanic() at vpanic+0x182/frame 0xfe01226a3460 > > kassert_panic() at kassert_panic+0x126/frame 0xfe01226a34d0 > > ipfw_rewrite_rule_uidx() at ipfw_rewrite_rule_uidx+0x258/frame > > 0xfe01226a356 > > 0 > > > > Yes; ref. <http://docs.FreeBSD.org/cgi/mid.cgi?20151103140436.GJ21127> > et seq. > > For me, the problem was with r290334; r290345 fixed it (again, for me). > Mine was at r290340, so I was caught in the middle :-) -- Mark Felder ports-secteam member f...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
IPFW panic on boot
Recent ipfw commits now cause my firewall to panic on boot. I had to revert them and only pull in Adrian's ath fix which was to fix yet a different panic I was encountering... :-) KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01226a33e0 vpanic() at vpanic+0x182/frame 0xfe01226a3460 kassert_panic() at kassert_panic+0x126/frame 0xfe01226a34d0 ipfw_rewrite_rule_uidx() at ipfw_rewrite_rule_uidx+0x258/frame 0xfe01226a356 0 commit_rules() at commit_rules+0x43/frame 0xfe01226a35b0 add_rules() at add_rules+0x430/frame 0xfe01226a3680 ipfw_ctl3() at ipfw_ctl3+0x424/frame 0xfe01226a3980 rip_ctloutput() at rip_ctloutput+0x261/frame 0xfe01226a39b0 sogetopt() at sogetopt+0x76/frame 0xfe01226a3a40 kern_getsockopt() at kern_getsockopt+0xde/frame 0xfe01226a3ab0 sys_getsockopt() at sys_getsockopt+0x50/frame 0xfe01226a3ae0 amd64_syscall() at amd64_syscall+0x2de/frame 0xfe01226a3bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01226a3bf0 --- syscall (118, FreeBSD ELF64, sys_getsockopt), rip = 0x800b2cbca, rsp = 0x7ff fca88, rbp = 0x7fffdb60 --- KDB: enter: panic -- Mark Felder ports-secteam member f...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RCTL and VIMAGE for 11.0-RELEASE
Hi all, Now that the internet has reached peak container, I would like to see less barriers of entry for deploying such environments on FreeBSD. This includes enabling RCTL and VIMAGE in CURRENT so we can hopefully ship them with 11.0-RELEASE. I know of a moderately sized deployment of jails+RCTL to keep customer webhosting in check and it purportedly works well. I don't have a lot of experience with VIMAGE, but it worked in a few lab environments I played with a while ago. What is preventing RCTL from being enabled right now? Any known/serious blockers? And the same for VIMAGE? I know there were issues with some firewalls, but I'm not sure where that stands today. Does it degrade network performance in a measurable way? Thanks ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RCTL and VIMAGE for 11.0-RELEASE
On Mon, Aug 24, 2015, at 14:18, Bjoern A. Zeeb wrote: On 24 Aug 2015, at 19:08 , Mark Felder f...@freebsd.org wrote: What is preventing RCTL from being enabled right now? Any known/serious blockers? It’s enabled in GENERIC. This is great news! https://svnweb.freebsd.org/base/head/sys/amd64/conf/GENERIC?r1=282900r2=282901; It also appears to be in 10.2-RELEASE -- I missed this. That helps a lot... And the same for VIMAGE? I know there were issues with some firewalls, but I'm not sure where that stands today. Does it degrade network performance in a measurable way? Ignoring performance for a second, there is more than just firewalls that needs to be done. I started writing a plan for the next 4 months yesterday. Most of this was done a few years ago and never made it to HEAD. It needs to be re-validated. If my plan comes together we’ll have another 4 month window before the 11 release cycle will start. /bz Thanks for taking time to fill me in on this. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg with an ssh repo crashes CURRENT
On Thu, Aug 20, 2015, at 17:18, Konstantin Belousov wrote: On Thu, Aug 20, 2015 at 03:26:10PM -0500, Mark Felder wrote: I've recreated this in a bhyve VM with the latest CURRENT snapshot, r286893. You can grab the whole /var/crash dump at https://feld.me/freebsd/crash.tar.gz vmcore is useless without matching kernel.debug. I've pasted the ps output below, but it's also included in the info.0 file. And this is not very useful without the preceeding panic message and other bits from the panic handler. I guess the process 666 was current when the panic occured ? Basically, what I want is to see the p_reaper value for the process with the pid 667. Even just p_reaper-p_pid is enough. Do you need me to recreate the issue and provide you a matching vmcore and kernel.debug as well as full scrollback before the panic message and ddb output (bt, ps, etc) ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg with an ssh repo crashes CURRENT
On Thu, Aug 20, 2015, at 15:26, Mark Felder wrote:
diff --git a/sys/kern/kern_procctl.c b/sys/kern/kern_procctl.c
index d65ba5a..8ef72901 100644
--- a/sys/kern/kern_procctl.c
+++ b/sys/kern/kern_procctl.c
@@ -187,8 +187,6 @@ reap_status(struct thread *td, struct proc *p,
}
} else {
rs-rs_pid = -1;
- KASSERT(LIST_EMPTY(reap-p_reaplist), (reap children
list));
- KASSERT(LIST_EMPTY(reap-p_children), (children
list));
}
return (0);
}
I'll try compiling a kernel with your patch and see what happens.
I can confirm that this fixes the crashes.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg with an ssh repo crashes CURRENT
On Thu, Aug 20, 2015, at 06:50, Konstantin Belousov wrote: On Wed, Aug 19, 2015 at 04:52:56PM -0500, Mark Felder wrote: panic: children list cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01228ea840 vpanic() at vpanic+0x189/frame 0xfe01228ea8c0 kassert_panic() at kassert_panic+0x132/frame 0xfe01228ea930 kern_procctl_single() at kern_procctl_single+0x81c/frame 0xfe01228eaa00 kern_procctl() at kern_procctl+0x223/frame 0xfe01228eaa50 sys_procctl() at sys_procctl+0xa5/frame 0xfe01228eaae0 amd64_syscall() at amd64_syscall+0x282/frame 0xfe01228eabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01228eabf0 The fired assert means that there was a reaper process with some children but without descendands to be reaped. Hm, I can imagine this situation to happen if e.g. some not-reaper forks and then acquires reaper status. The patch below removes too aggressive asserts. Still, it would be interesting to look into the process table. Please repeat the procedure to panic, then in ddb do 'ps'. After that do 'dump' and please keep kernel.debug and vmcore around. First I want to look at the ps output. I've recreated this in a bhyve VM with the latest CURRENT snapshot, r286893. You can grab the whole /var/crash dump at https://feld.me/freebsd/crash.tar.gz I've pasted the ps output below, but it's also included in the info.0 file. Stopped at kdb_enter+0x3e: movq$0,kdb_why db ps pid ppid pgrp uid state wmesg wchancmd 667 666 665 0 S+ select 0xf80003c53840 ssh 666 665 665 0 R+ CPU 0 pkg 665 629 665 0 S+ wait 0xf800039e0548 pkg 629 628 629 0 S+ pause0xf8001947eb38 csh 628 1 628 0 Ss+ wait 0xf80003db8a90 login 627 1 627 0 Ss+ ttyin0xf80003c0f0a8 getty 626 1 626 0 Ss+ ttyin0xf80003c0f4a8 getty 625 1 625 0 Ss+ ttyin0xf8000387a0a8 getty 624 1 624 0 Ss+ ttyin0xf8000387a4a8 getty 623 1 623 0 Ss+ ttyin0xf8000387a8a8 getty 622 1 622 0 Ss+ ttyin0xf8000387aca8 getty 621 1 621 0 Ss+ ttyin0xf8000387b0a8 getty 620 1 620 0 Ss+ ttyin0xf8000387b4a8 getty 577 1 577 0 Ss nanslp 0x81ab2561 cron 573 1 57325 Ss pause0xf80003d040a8 sendmail 570 1 570 0 Ss select 0xf80003849c40 sendmail 542 1 542 0 Ss select 0xf80003c53ec0 sshd 443 1 443 0 Ss select 0xf80003849d40 casperd 442 1 442 0 Ss select 0xf80003c540c0 casperd 342 1 342 0 Ss select 0xf80003849dc0 syslogd 271 1 271 0 Ss select 0xf80003849ec0 devd 16 0 0 0 DL vlruwt 0xf800039e0a90 [vnlru] 15 0 0 0 DL syncer 0x81c41cf8 [syncer] 14 0 0 0 DL (threaded) [bufdaemon] 100042 D psleep 0x81c40f04 [bufdaemon] 100057 D sdflush 0xf80003d870e8 [/ worker] 9 0 0 0 DL pgzero 0x81c4aee4 [pagezero] 8 0 0 0 DL psleep 0x81c4a6b8 [vmdaemon] 7 0 0 0 DL (threaded) [pagedaemon] 100039 D psleep 0x81cf6684 [pagedaemon] 100045 D umarcl 0x81c4a040 [uma] 6 0 0 0 DL waiting_ 0x81ce8640 [sctp_iterator] 5 0 0 0 DL (threaded) [cam] 100017 D -0x818d6e00 [doneq0] 100038 D -0x818d6c48 [scanner] 4 0 0 0 DL crypto_r 0x81c48b88 [crypto returns] 3 0 0 0 DL crypto_w 0x81c48a30 [crypto] 13 0 0 0 DL (threaded) [geom] 100010 D -0x81cc0aa0 [g_event] 100011 D -0x81cc0aa8 [g_up] 100012 D -0x81cc0ab0 [g_down] 12 0 0 0 WL (threaded) [intr] 16 I [swi4: clock (0)] 17 I [swi4: clock (1)] 18 I [swi3: vm] 19 I [swi1: netisr 0] 100018 I [swi6: task queue] 100019 I [swi6: Giant taskq] 100021 I
pkg with an ssh repo crashes CURRENT
Hello,
I found a reproducible way to crash CURRENT. I've done so on a Raspberry
Pi 2 running r286596 and an my x86_64 firewall running r286285.
Setup is simple. Enable a functional pkg repo that uses ssh like so:
myrepo: {
url:
ssh://feld@172.16.1.122/usr/local/poudriere/data/packages/${ABI}/,
enabled: no
}
Now just do a pkg upgrade or install. So far the crashes have always
happened updating pkg itself; I haven't gotten past that part.
My firewall has a watchdog so it auto-reboots and I don't have console
or video on my Rpi2 at the moment so I can't tell where it's crashing
at. I haven't seen any dumps or core files. I got a glimpse of the crash
on the firewall once and I think I saw it spew out some LORs, but I'm
not certain. I'll try to get more data posted soon, but if someone is
feeling adventurous they can probably reproduce this in a matter of
minutes.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pkg with an ssh repo crashes CURRENT
Here we go: root@gw:/usr/home/feld # pkg upgrade Updating me repository catalogue... Password for f...@skeletor.feld.me: me repository is up-to-date. All repositories are up-to-date. New version of pkg detected; it needs to be installed first. The following 1 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: pkg: 1.5.5 - 1.5.6 The operation will free 10 KiB. 2 MiB to be downloaded. Proceed with this action? [y/N]: y lock order reversal: 1st 0xfe00f52a8e00 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3191 2nd 0xf8001747e000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01228ea400 witness_checkorder() at witness_checkorder+0xe7a/frame 0xfe01228ea480 _sx_xlock() at _sx_xlock+0x75/frame 0xfe01228ea4c0 ufsdirhash_add() at ufsdirhash_add+0x3d/frame 0xfe01228ea510 ufs_direnter() at ufs_direnter+0x5da/frame 0xfe01228ea5e0 ufs_makeinode() at ufs_makeinode+0x5d3/frame 0xfe01228ea7a0 ufs_create() at ufs_create+0x2d/frame 0xfe01228ea7c0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe01228ea7f0 vn_open_cred() at vn_open_cred+0x30e/frame 0xfe01228ea960 kern_openat() at kern_openat+0x235/frame 0xfe01228eaae0 amd64_syscall() at amd64_syscall+0x282/frame 0xfe01228eabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01228eabf0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x8024a8f7a, rsp = 0x7fffd458, rbp = 0x7fffd550 --- lock order reversal: 1st 0xf800785047c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2219 2nd 0xfe00f52a8e00 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263 3rd 0xf800784ea5f0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2219 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01228e9df0 witness_checkorder() at witness_checkorder+0xe7a/frame 0xfe01228e9e70 __lockmgr_args() at __lockmgr_args+0xa5c/frame 0xfe01228e9fa0 ffs_lock() at ffs_lock+0x84/frame 0xfe01228e9ff0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe01228ea020 _vn_lock() at _vn_lock+0x9a/frame 0xfe01228ea090 vget() at vget+0x7e/frame 0xfe01228ea0e0 vfs_hash_get() at vfs_hash_get+0xcc/frame 0xfe01228ea130 ffs_vgetf() at ffs_vgetf+0x40/frame 0xfe01228ea1c0 softdep_sync_buf() at softdep_sync_buf+0xa8f/frame 0xfe01228ea2a0 ffs_syncvnode() at ffs_syncvnode+0x259/frame 0xfe01228ea320 ffs_truncate() at ffs_truncate+0x6f4/frame 0xfe01228ea510 ufs_direnter() at ufs_direnter+0x767/frame 0xfe01228ea5e0 ufs_makeinode() at ufs_makeinode+0x5d3/frame 0xfe01228ea7a0 ufs_create() at ufs_create+0x2d/frame 0xfe01228ea7c0 VOP_CREATE_APV() at VOP_CREATE_APV+0xf1/frame 0xfe01228ea7f0 vn_open_cred() at vn_open_cred+0x30e/frame 0xfe01228ea960 kern_openat() at kern_openat+0x235/frame 0xfe01228eaae0 amd64_syscall() at amd64_syscall+0x282/frame 0xfe01228eabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01228eabf0 --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x8024a8f7a, rsp = 0x7fffd458, rbp = 0x7fffd550 --- Fetching pkg-1.5.6.txz: 100%2 MiB 2.5MB/s00:01 Checking integrity... done (0 conflicting) [1/1] Upgrading pkg from 1.5.5 to 1.5.6... panic: children list cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01228ea840 vpanic() at vpanic+0x189/frame 0xfe01228ea8c0 kassert_panic() at kassert_panic+0x132/frame 0xfe01228ea930 kern_procctl_single() at kern_procctl_single+0x81c/frame 0xfe01228eaa00 kern_procctl() at kern_procctl+0x223/frame 0xfe01228eaa50 sys_procctl() at sys_procctl+0xa5/frame 0xfe01228eaae0 amd64_syscall() at amd64_syscall+0x282/frame 0xfe01228eabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01228eabf0 --- syscall (544, FreeBSD ELF64, sys_procctl), rip = 0x80244bc7a, rsp = 0x7fffd2c8, rbp = 0x7fffd410 --- KDB: enter: panic [ thread pid 1586 tid 100146 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db db bt Tracing pid 1586 tid 100146 td 0xf800784214d0 kdb_enter() at kdb_enter+0x3e/frame 0xfe01228ea840 vpanic() at vpanic+0x1a9/frame 0xfe01228ea8c0 kassert_panic() at kassert_panic+0x132/frame 0xfe01228ea930 kern_procctl_single() at kern_procctl_single+0x81c/frame 0xfe01228eaa00 kern_procctl() at kern_procctl+0x223/frame 0xfe01228eaa50 sys_procctl() at sys_procctl+0xa5/frame 0xfe01228eaae0 amd64_syscall() at amd64_syscall+0x282/frame 0xfe01228eabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01228eabf0 --- syscall (544, FreeBSD ELF64, sys_procctl), rip = 0x80244bc7a, rsp = 0x7fffd2c8, rbp = 0x7fffd410 --- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Turbulence in head @r282676.
On Sun, May 10, 2015, at 12:39, Alan Cox wrote: This is fixed in r282706. The r282694 snapshots (amd64 at least) are useless because of this bug and was causing me constant crashing. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sbuf-related panic
On Tue, Mar 17, 2015, at 13:57, Ian Lepore wrote: On Tue, 2015-03-17 at 13:49 -0500, Mark Felder wrote: On Mon, Mar 16, 2015, at 13:03, Shawn Webb wrote: On amd64, doing a Poudriere run. On r280133: I appeared to be hitting this on 280130, the most recent CURRENT snapshot. I'm going to build the latest since some sbuf fixes have landed and see if I can finish a poudriere build run. There is still a panic, one that I can't yet figure out why it wasn't panicking before my changes, but I'm working on it. Is the previous snapshot -- r279813 -- old enough to have missed the related changes? I'm just trying to get a machine up from 10.1-RELEASE to relatively CURRENT quickly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Shared object libsodium.so.13 not found, required by dnscrypt-proxy
On Mon, Feb 23, 2015, at 12:43, Miguel Clara wrote: I don't think this is a 11-Current issue per say but probalby bad config, but since I'm using CURRENT I dicided to post to the list. When my system boots dnscrypt fails to start with: Shared object libsodium.so.13 not found, required by dnscrypt-proxy But manual start works without issue, I've resinstalled libsodium and dnscrypt from ports and I noticed USE_LDCONFIG= yes is present in the Makefile for libsodium, Running dmesg -a I see this relvant part: % dmesg -a | grep dns -A20 Starting dnscrypt_proxy. Shared object libsodium.so.13 not found, required by dnscrypt-proxy /etc/rc: WARNING: failed to start dnscrypt_proxy Starting local_unbound. Starting pflogd: Starting pflog. pflog0: promiscuous mode enabled Enabling pfNo ALTQ support in kernel ALTQ related functions disabled No ALTQ support in kernel ALTQ related functions disabled . add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net :::0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net default: gateway fe80::62a4:4cff:fe28:13c0%wlan0 Waiting 30s for the default route interface: .(no carrier) ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat /usr/local/lib/gcc47 /usr/local/lib/libxul /usr/local/lib/nss /usr/local/llvm35/lib 32-bit compatibility ldconfig path: /usr/lib32 /usr/local/lib32/compat So it seems that the issue is that ldconfig runs after the service is started and so when it starts I doens't know about the shared lib (or where to look for it) How can I fix this behaviour? If you edit the dnscrypt-proxy rc script to say: # REQUIRE: SERVERS cleanvar ldconfig Does that help? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Memory corruption in a master perl process after child exits - only under FreeBSD 10.0 amd64 (not in 10.1 or 9.*)
On Mon, Jan 26, 2015, at 13:32, Mark Martinec wrote: There is a problem report since July 2014 in a Perl bug tracker, which seems to affect only FreeBSD 10.0 amd64 (regardless of a version of Perl or usage of clang vs. gcc compiler): https://rt.perl.org/Ticket/Display.html?id=122199 Given the ability to reproduce this 100% it seems perfect for using git bisect command to figure out which commit between 10.0 and 10.1 solves this. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On Tue, Nov 11, 2014, at 13:16, Dimitry Andric wrote: On 11 Nov 2014, at 04:28, Mark Felder f...@freebsd.org wrote: On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( I think this was one of the crowning achievements of systemd, but I'm sure someone can come up with something much more sane than that to address this problem. Actually, it isn't: http://www.freedesktop.org/wiki/Software/systemd/timedated/ This reads Note that this service will not inform you about system time changes. Use timerfd() with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET for that. So it mostly looks like a shared service to provide the graphical time control panel for GNOME. Aha, I guess the article I read was as reliable as jamming all that code into PID 1. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Changing timezone without reboot/restarting each service?
On Mon, Nov 10, 2014, at 06:36, Lev Serebryakov wrote: After changing timezones in Russia (with replacing /etc/localtime with new file), I found that cron works in old timezone till restart. And all other services do the same, but cron is most obvious here :) Looks like libc reads timezone only once and it could not be chamged for process without restart (which leads to, effectivly, restart of whole server). Is it known problem? I think, it should be fixed somehow. I understand, that re-check timezone file on each time-related call could be expensive, though :( I think this was one of the crowning achievements of systemd, but I'm sure someone can come up with something much more sane than that to address this problem. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
Any hope of zfsd before the freeze for 10.1-RELEASE? Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
August 26 2014 2:45 PM, Alan Somers asom...@freebsd.org wrote: On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder f...@freebsd.org wrote: August 26 2014 10:21 AM, Alan Somers asom...@freebsd.org wrote: Merged into the projects/zfsd/head branch by change 270604. Merging to head is blocked by three issues: a) The atf-ksh93 hack. The correct solution is to modify all the test programs (not the test cases) so they can run under /bin/sh. That will take some effort. Can you provide a link to the atf-ksh93 code? There's not much to it. It simply sets an environment variable and calls atf-sh. What's more interesting is libtest.kshlib. In order to eliminate atf-ksh93, we would need to modify libtest.kshlib to run under /bin/sh. Alternatively, it may be easier to split libtest.kshlib into two files: a small /bin/sh-compatible that can be sourced by the ATF test programs, and a ksh93 script that only needs to be sourced by the ATF test cases. https://svnweb.freebsd.org/base/projects/zfsd/head/libexec/atf/atf-ksh93/ https://svnweb.freebsd.org/base/projects/zfsd/head/tests/sys/cddl/zfs/include/libtest.kshlib Depending on how complicated it is we might be able to coerce dteske into checking it out. He could write an sh mastery book... I'm sure he could assist with this. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
August 26 2014 2:49 PM, Garrett Cooper yaneurab...@gmail.com wrote: Why not just require ksh93 from ports? Because zfsd is going to be in base, not in ports. Everything in base needs to work without any ports requirements. Also ksh93 has been... problematic. It has a history of breaking on i386, sparc64, current, etc. It's not exactly a reliable dependency. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
July 31 2014 2:41 AM, Darren Pilgrim wrote: No. I believe pf should be removed from FreeBSD and efforts refocused on keeping ipfw up to date and feature complete. It makes more sense to look at what pf, ipf, nbtables, etc. are all doing as a source of ideas for what we can do with ipfw. A decade ago, there was justification for adding pf: at the time, ipfw lacked some major features. Ipfw has since caught up. I see no remaining value in having more than one packet filter in the base. Ipfw is more mature and less broken, so we should keep it and ditch the rest in the name of survival efficiency. pf is not simply replaceable in many environments. For example, people use it specifically for its integration with the spamd greylisting daemon. I think it's reasonable to assume they did so because the whole spam filtering stack performs better on FreeBSD than on OpenBSD. This was just recently mentioned on twitter: @ng_security Why was the pf ioctl needed buffer reduced in FreeBSD 10? I'm not able to load my full spamd blacklist anymore. @freebsd #spamd #pf https://twitter.com/ng_security/status/494982307905040384 I personally use pf for many reasons, spamd included. I don't think anyone out there is interested in forking spamd to play ball with ipfw so we would also be alienating these users who can't just change packet filters. Is there even an equivalent to pfsync for ipfw? I didn't think so, but I could be wrong... In the world of firewalls pf has been put on a quite a pedestal. OpenBSD pushed it hard and it marketed it well; people found it both powerful and easy to use which created a cult following and lots of word of mouth advertising. I find it hard to agree with removing pf from FreeBSD because of the existing userbase. If there was an experimental label on it I would find its removal easier to swallow. I think it's worth pointing out that nobody really wanted to maintain an incompatible fork of ZFS indefinitely either; it would be a monumental if not suicidal task. And who wants to deal with the bad PR about FreeBSD being years behind Illumos features or, *gasp*, even letting a native Linux implementation one-up us? People found a way to collaborate, OpenZFS movement was founded, and this is a mostly solved problem, OS nuances aside. I can appreciate that people seem to care more about their data than their packet filters and FreeBSD ZFS certainly moves a lot of servers and appliances furthering the userbase whether or not they're using FreeBSD or TrueOS or some other derivative. Let's continue to give people another reason to put FreeBSD in their datacenters. Let's try to compete in the firewall/packet filter space too. On a side note I'd also like to point out that FreeBSD has been advertising pf by listing it first in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html I'm sure there's a subliminal message being sent there, intentional or not. I don't want to see FreeBSD lose mindshare from its absence in a time where FreeBSD uptake seems to be rising thanks in part to bad decisions in the GNU/Linux camp. This feels like a solvable problem if funding and enthusiasm is put behind it. OpenBSD really sounds willing to collaborate if not just because they're tired of seeing neglected forks of one of their prized babies: FreeBSD, NetBSD, DragonFlyBSD, OSX, iOS... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
We've already heard of Henning offering to help port a new pf but the olive branch has been extended even further. He responded to some comments of mine on twitter: @HenningBrauer: @rhymebyter @feldpos I offered help/advice to whomever seriously attempts to update pf in @dragonflybsd AND @freebsd. @HenningBrauer: @feldpos it takes someone in freebsd/netbsd/dragonfly to update their ancient pf versions, then code can flow bidirectional Technical hurdles aside, that sounds like the beginning of an OpenPf to me... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Jul 23, 2014, at 15:59, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: There was (is?) another case that in certain situations with certain pf options IPv6/ULP packets would not pass or get corrupted. I think no one who experienced it never tracked it down to the code but I am sure there are PRs for this; best bet is that not all header sizes are equal and length/offsets into IPv6 packets are different to IPv4, especially when you scrub. scrub reassemble tcp breaks all ipv6 tcp traffic since FreeBSD 9.0. Well, not entirely breaks but things seem to be going at a rate of a poor dialup connection. This is similar to what I've experienced with pf + tso on Xen. Related? Possibly! I'd hazard a guess the reassembling of tcp on IPv6 is breaking checksums? Upstream pf from OpenBSD has removed this feature entirely and (I believe) reworked their scrubbing, but I don't know the details. I can confirm that when reassemble tcp existed on OpenBSD it never broke traffic for me. Synproxy and IPv6 was also broken last I knew. I can't remember the symptoms, but it was probably nothing works. I recall synproxy has always been one of those you're gonna shoot your eye out kid features, but some people have used it successfully. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Jul 24, 2014, at 13:43, Mark Felder f...@freebsd.org wrote: Upstream pf from OpenBSD has removed this feature entirely and (I believe) reworked their scrubbing, but I don't know the details. I can confirm that when reassemble tcp existed on OpenBSD it never broke traffic for me. I'm wrong; reassemble tcp still exists upstream. I must be thinking of something else that has since been removed but exists in our version. Oh well. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Jul 19, 2014, at 3:35, Andreas Nilsson andrn...@gmail.com wrote: On Sat, Jul 19, 2014 at 4:40 AM, Darren Pilgrim list_free...@bluerosetech.com wrote: On 7/18/2014 4:06 AM, Gleb Smirnoff wrote: K b) We are a major release away from OpenBSD (5.6 coming soon) - is K following OpenBSD's pf the past? - should it be? Following OpenBSD on features would be cool, but no bulk imports would be made again. Bulk imports produce bad quality of port, and also pf in OpenBSD has no multi thread support. I would much rather have a slower pf that actually supports modern networking than a faster one I can't use due to showstopper flaws and missing features. So would I. Not that we use pf, but anyway. There is currently no viable firewall module for FreeBSD if you want to do things like route IPv6. Isn't that possible with ipfw? Perhaps the pf guys in OpenBSD could be convinced to start openpf and have porting layer as in openzfs. I do not know ipfw IPv6 limitations, but the Wikipedia article says: * IPv6 support (with several limitations) Choice is nice, but I would like to see the project promote one firewall to users. My coworkers long ago jumped ship from ipfw to pf and I know regret that decision due to the IPv6 bugs. At this point it's too hard to migrate all the servers off of pf. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
July 18 2014 6:07 AM, Gleb Smirnoff wrote: Kristian, On Thu, Jul 17, 2014 at 01:12:09AM +0200, Kristian K. Nielsen wrote: K a) First of all - are any actively developing pf in FreeBSD? No one right now. How do we fix this? Can the FreeBSD Foundation step in and provide funding? Our most popular firewall doesn't play well with IPv6 in a time when everyone is pushing IPv6. This is not exactly a good situation to be in. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PostgreSQL performance on FreeBSD
June 27 2014 7:56 AM, Konstantin Belousov wrote: Hi, I did some measurements and hacks to see about the performance and scalability of PostgreSQL 9.3 on FreeBSD, sponsored by The FreeBSD Foundation. The results are described in https://kib.kiev.ua/kib/pgsql_perf.pdf. The uncommitted patches, referenced in the article, are available as https://kib.kiev.ua/kib/pig1.patch.txt https://kib.kiev.ua/kib/patch-2 Thank you for taking the time to do this benchmark. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: using single gcc compiler
On 2014-06-02 07:05, MS - Krasznai András wrote: Hi I use freebsd-10 as desktop . Compiling the system takes ages, and rather long time is spent in compiling different gcc compiler versions for various ports, e.g. - gcc-4.7.3- required by avidemux; - gcc-4.6.4_1,1: required by opera,operaplugins, gcc, gcc4.8 - gcc 4.8.4_xxx: required by rawtherapee Is there a way to specify that I want to use gcc 4.8.4 for all compilations which do not use clang? Some ports only work with specific versions of GCC. If you believe a specific port should be able to use GCC 4.8.4 I would recommend testing it and filing a PR so the port maintainer can confirm and update the port. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Change top's notion of idle processes / threads
On May 28, 2014, at 9:54, John Baldwin j...@freebsd.org wrote: Yes, I actually started by sorting on the raw delta and ended up going back and fixing pctcpu instead. However, there is a problem in this case which is that you still want to fall back to ki_pctcpu if you don't have a valid previous delta to compare against. It's a lot simpler to just fixup ki_pctcpu and not have to go change the sorting code explicitly. :( I actually started out having a function that returned a double for the pctcpu, but that would mean recalculating the raw pctcpu many, many times during the sort. Just updating ki_pctcpu once per each process/thread per fetch scales a bit better. I could perhaps use an array to cache raw percentages as doubles. Ok, try people.freebsd.org/~jhb/patches/top_pctcpu2.patch Hey, all the 0.00% processes on my server now show up in top with measurable usage. Nice. (They're all between 0.3% and 0.9%) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ordering for network-sensitive rc scripts
On Apr 17, 2014, at 3:21, David Chisnall thera...@freebsd.org wrote: Hi all, For a little while, I've had an issue with the machine that sits on the edge of my network deciding to start avahi as soon as a network is available, meaning that it then runs mDNS advertisements on the external interface and not the wireless one, requiring a manual restart once the machine boots. I'm now seeing something similar with pf - it manages to start before the external interface comes up and so silently ignores all of the rules for routing packets off the network. Do we have a mechanism for stating that certain services should not be started until ALL of the interfaces are up, rather than just the first one? Or even of restarting them when a new network appears? I always thought the proper solution here was pf's built-in keywords egress and ingress interface names so you don't have to specify interface names that may or may not exist at the time the pf rules load. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Dragonfly DMA: bare to address difference with sendmail
On 2014-03-25 07:06, Lev Serebryakov wrote: Hello, Freebsd-current. When I use sendmail, all output of periodic scripts is received with root@host To: address. with dma it is only root. IMHO, it is regression, as I collect all mail on one server/account and now all these To fields are the same :) I've reported this to bapt. This is a regression and doesn't follow the RFCs. He said he knew how to fix it, but I haven't verified if anything was checked in to head. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using of Dragonfly Mail Agent -- what should be permissions on dma.conf and auth.conf?
On 2014-03-24 06:53, Lev Serebryakov wrote: Hello, Freebsd-current. I've tried 440 with owner 25:25 and mail l...@serebryakov.spb.ru complains, that it could not access them. Also, what is proper way to attach dma into system instead of senndmal now? I'm not sure what the permissions of those files should really be, but this is likely what you want in mailer.conf: sendmail/usr/libexec/dma send-mail /usr/libexec/dma mailq /usr/libexec/dma and rc.conf: sendmail_enable=NO sendmail_submit_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
Hi guys, Any updates? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help
On Thu, Mar 6, 2014, at 2:59, Anton Shterenlikht wrote: In my initial PR (sparc64 r261798), http://www.freebsd.org/cgi/query-pr.cgi?pr=187080 I said that rsync was triggering this panic. While true, I now see that there's more to it. I disabled the rsync, and the cron jobs. Still I get exactly the same panic every night at 03:02: # grep Dumptime /var/crash/* /var/crash/info.0: Dumptime: Wed Feb 26 10:10:51 2014 /var/crash/info.1: Dumptime: Thu Feb 27 03:02:14 2014 /var/crash/info.2: Dumptime: Fri Feb 28 03:02:29 2014 /var/crash/info.3: Dumptime: Sat Mar 1 03:02:25 2014 /var/crash/info.4: Dumptime: Tue Mar 4 03:02:01 2014 /var/crash/info.5: Dumptime: Wed Mar 5 03:02:05 2014 /var/crash/info.6: Dumptime: Thu Mar 6 03:02:11 2014 /var/crash/info.last: Dumptime: Thu Mar 6 03:02:11 2014 # This is likely triggered by one of the daily periodic scipts, after about 1 min from start: # grep daily /etc/crontab # Perform daily/weekly/monthly maintenance. 1 3 * * * rootperiodic daily # but which one? Can you go into /etc/periodic/daily and execute those scripts one by one? You should be able to narrow down which one is the culprit. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help
On Thu, Mar 6, 2014, at 11:28, Lowell Gilbert wrote: Glen Barber g...@freebsd.org writes: On Thu, Mar 06, 2014 at 07:49:42AM -0800, Anton Shterenlikht wrote: Can you go into /etc/periodic/daily and execute those scripts one by one? You should be able to narrow down which one is the culprit. unfortunately I cannot reproduce the panic this way. What I did was: # cd /etc/periodic/daily # for file in `ls` do echo $file ./$file done I run it twice, I could see all scripts executing one after another, but no panic. Perhaps something else is happening at the same time as daily scripts? But I cannot find what. It can also be one of the scripts in /etc/periodic/security. Can you retry your test in that directory, as well? periodic daily would be a slightly better test... That won't help him narrow down the exact periodic script causing it, which is what he's trying to do. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Tue, Feb 25, 2014, at 10:07, Michel Talon wrote: Thomas Mueller wrote There needs to be better documentation of sendmail if it is to be kept, and the option to compile sendmail for fuller function including SSL and TLS Apparently sendmail is compiled with ssl/tls support in FreeBSD, standard. This is what i get by sending mail from my freshly installed FreeBSD-10 machine niobe to the lab's mailhub (running postfix) Yes, however the Sendmail in base on FreeBSD 8 and 9 is compiled against OpenSSL 1.0 which means it's missing support for TLS 1.2, SNI, and other modern best practice features. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Mon, Feb 24, 2014, at 3:41, Joe Holden wrote: On 24/02/2014 04:26, Julio Merino wrote: On Sun, Feb 23, 2014 at 4:11 PM, Baptiste Daroussin b...@freebsd.orgwrote: Hi, As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. DragonFly Mail Agent is a minimalistic mailer that is able to relay mails to some smtp servers (with TLS, authentication and so on) It supports MASQUERADE and NULLCLIENT, and is able to deliver mails locally (respecting aliases). I imported it because dma is lightweight, BSD license and easy to use. The code base is rather small and easy to capsicumize (which I plan to do) My initial goal is not to replace sendmail. But is it an eventual goal? *I* don't see why not, but if it is: what's the plan? How is the decision to drop sendmail going to be made when the time comes? (I.e. who _can_ and will make the call?) All I want is a small mailer simple to configure, and not listening to port 25, suitable for small environment (embedded and/or resource bounded) as well as for server deployment. Playing devil's advocate: what specific problems is this trying to solve? I'd argue, for example, that postfix can be also easily configured and can be made to not listen on port 25 for local mail delivery, while at the same time it is a fully-functional MTA that could replace sendmail altogether. (Which, by the way, is the configuration with which postfix ships within the NetBSD base system.) The reason I'm asking these questions is because I have seen NetBSD maintain two MTAs (sendmail + postfix) in the base system for _years_ and it was not a pretty situation. The eventual removal of sendmail was appreciated, but of course it came with the associated bikeshedding. *dons flame-proof suit* The trend towards having sensible lightweight things in the base is a good thing IMO. There is no need for things like bind (replaced by unbound), or a full featured mta like sendmail in the base, base install should contain enough to get going but for specific functions like performing MTA tasks, the user can install the appropriate software, such as postfix. Just my 2p :) I fully agree here. Lightweight services in base, fully featured in ports. It makes it easier for users to follow the latest and greatest MTA, DNS, etc this way as well. Another nice feature of dma is that it's a perfect compliment to your lightweight jails -- emails can get out, but no worrying about conflicts on ports 25. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Mon, Feb 24, 2014, at 8:56, Daniel Kalchev wrote: On 24.02.14 13:47, Thomas Mueller wrote: I don't believe BSD users use base system of itself to send and receive email. They use ports (FreeBSD) or equivalent in other BSDs. One of the beauties of the BSD 'base system' is that upon installation you have an usable workstation/server environment that can be immediately used for most Internet-related tasks -- and this most certainly includes SMTP. Or NTP. Or... used to include DNS. And one of the warts is our dedication to long support on FreeBSD releases; FreeBSD 8 is still supported with 8.3 and 8.4 releases. RELENG_8 was branched in August of 2009. FreeBSD 8.4 has an estimated EoL of June 30 2015. This is nearly 6 years since the original release -- an incredible amount of time to be maintaining such complex software. (Though I'm aware that Sendmail's release process is rather slow) We can strip pieces of FreeBSD off and end up with an kernel. Or we could keep the system very much usable out of the box. Imagine a world where everything in FreeBSD is a package and we have a working PROVIDES framework. Upon installation you can choose the software that provides the MTA role. Same for DNS, NTP, database, webserver... That would be a great accomplishment along with a framework to create a master install image utilizing the options/packages you desire. I think this type of thing is definitely plausible if we keep moving forward. My personal opinion remains that complex software is better served/secured/maintained when it is handled in ports not in base. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Mon, Feb 24, 2014, at 9:50, Lyndon Nerenberg wrote: On Feb 24, 2014, at 7:40 AM, Bryan Drewery bdrew...@freebsd.org wrote: Anything not meeting the bare-bones criteria can be installed with 'pkg install' or ports. Try this in a shop where all your machines are completely air-gapped from the internet. Email had 1 attachment: + signature.asc 1k (application/pgp-signature) You might want to consult with Devin Teske. He deals with mass installations of airgapped FreeBSD and may be able to lend some tips on how he has tackled such challenges provided he doesn't have a massive NDA preventing him from talking about these high level details. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of DragonFly Mail Agent
On Mon, Feb 24, 2014, at 12:46, Bryan Drewery wrote: On 2/23/2014 3:11 PM, Baptiste Daroussin wrote: Hi, As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. Does this support a /usr/sbin/sendmail wrapper for sending mail through CLI? Yes. mailer.conf: sendmail/usr/local/libexec/dma send-mail /usr/local/libexec/dma mailq /usr/local/libexec/dma ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Apple Trackpad driver
On Tue, Jan 28, 2014, at 23:13, Adrian Chadd wrote: holy crap, cool! Hans? Any chance we could get this into -HEAD? Wow, this is nice. I'll gladly provide the USB device ID for the trackpad in the 2013 Late MBP if someone can point me to a way to boot FreeBSD from an external drive :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
I agree with the rest of this thread. This is just awful. I'm basically forced to do source based updates when jumping major versions because freebsd-update is a nightmare to use. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mtree acl support
On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote: On Jan 14, 2014, at 6:47 AM, Mark Felder f...@freebsd.org wrote: I was recently talking to someone about how one would backup / restore ACLs reliably. I didn't see any mention of ACLs in the mtree man page and after a quick google I came upon this old mailing list post: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff This old patch appears to still apply cleanly. I hate to see a patch die and be forgotten. One problem that ‘tar’ has addressed (inspired by Joerg Schilling’s work on star) is to permit ACLs to be restored even if the user database is out of date. This is done by including a fourth field in each ACE with the numeric user ID. I suspect you want to do the same for mtree. I thought I remembered acl_to_text having an option to use an extended text format, so it might be a trivial change. As long as it's not default. One of the most convenient ways to change a user's UID (or multiple users!) is to do an mtree backup, change UID/GID, and then re-apply mtree backup. Every file that the user(s) previously owned will be automatically changed to the new UID/GID for you :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
mtree acl support
I was recently talking to someone about how one would backup / restore ACLs reliably. I didn't see any mention of ACLs in the mtree man page and after a quick google I came upon this old mailing list post: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-April/024173.html patch in list is here: http://heka.cenkes.org/sat/diffs/mtree_acl.diff I've mirrored it here: https://feld.me/freebsd/mtree_acl.diff This old patch appears to still apply cleanly. I hate to see a patch die and be forgotten. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10.0-RC5 Now Available
On Thu, Jan 9, 2014, at 21:41, Erich Dollansky wrote: Hi, I upgraded this morning to FreeBSD X220.alogt.com 10.0-PRERELEASE FreeBSD 10.0-PRERELEASE #7 r260489: Fri Jan 10 08:25:55 WITA 2014 er...@x220.alogt.com:/usr/obj/usr/src/sys/X220 amd64 just to find out that the mouse is not working under X anymore. The ports are from revision 336079. I have an X220. Neither the internal stick nor the external USB connected Logitech Trackman work. Both work outside X. X logs these mouse related messages: [ 315.926] (==) intel(0): Silken mouse enabled [ 316.960] (II) config/hal: Adding input device Trackball [ 316.960] (II) LoadModule: mouse [ 316.961] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 316.977] (II) Module mouse: vendor=X.Org Foundation [ 316.977]compiled for 1.12.4, module version = 1.9.0 [ 316.977]Module class: X.Org XInput Driver [ 316.977]ABI class: X.Org XInput driver, version 16.0 [ 316.977] (II) Using input driver 'mouse' for 'Trackball' [ 316.977] (**) Trackball: always reports core events [ 316.977] (**) Option Device /dev/ums0 [ 316.977] (==) Trackball: Protocol: Auto [ 316.977] (**) Trackball: always reports core events [ 316.977] (EE) xf86OpenSerial: Cannot open device /dev/ums0 Device busy. [ 316.977] (EE) Trackball: cannot open input device [ 316.977] (EE) PreInit returned 2 for Trackball [ 316.977] (II) UnloadModule: mouse [ 316.991] (II) config/hal: Adding input device PS/2 Mouse [ 316.991] (II) Using input driver 'mouse' for 'PS/2 Mouse' [ 316.991] (**) PS/2 Mouse: always reports core events [ 316.991] (**) Option Device /dev/psm0 [ 316.991] (==) PS/2 Mouse: Protocol: Auto [ 316.991] (**) PS/2 Mouse: always reports core events [ 316.991] (EE) xf86OpenSerial: Cannot open device /dev/psm0 Device busy. [ 316.991] (EE) PS/2 Mouse: cannot open input device [ 316.991] (EE) PreInit returned 2 for PS/2 Mouse [ 316.991] (II) UnloadModule: mouse This are the X message I get when running X on an older release candidate: [ 111.171] (II) config/hal: Adding input device PS/2 Mouse [ 111.171] (II) LoadModule: mouse [ 111.171] (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so [ 111.181] (II) Module mouse: vendor=X.Org Foundation [ 111.181]compiled for 1.12.4, module version = 1.9.0 [ 111.181]Module class: X.Org XInput Driver [ 111.181]ABI class: X.Org XInput driver, version 16.0 [ 111.181] (II) Using input driver 'mouse' for 'PS/2 Mouse' [ 111.181] (**) PS/2 Mouse: always reports core events [ 111.181] (**) Option Device /dev/sysmouse [ 111.181] (==) PS/2 Mouse: Protocol: Auto [ 111.181] (**) PS/2 Mouse: always reports core events [ 111.181] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 [ 111.181] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 [ 111.181] (**) PS/2 Mouse: Buttons: 5 [ 111.181] (**) Option config_info hal:/org/freedesktop/Hal/devices/psm_0 [ 111.181] (II) XINPUT: Adding extended input device PS/2 Mouse (type: MOUSE, id 7) [ 111.181] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 [ 111.181] (**) PS/2 Mouse: (accel) acceleration profile 0 [ 111.181] (**) PS/2 Mouse: (accel) acceleration factor: 2.000 [ 111.181] (**) PS/2 Mouse: (accel) acceleration threshold: 4 [ 111.181] (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is 0 [ 111.182] (II) PS/2 Mouse: SetupAuto: protocol is SysMouse The same X worked perfectly with any FreeBSD 10 since BETA1. When I change xorg.conf and disable moused, I am able to get the internal mouse (stick) working but not the external one. The external mouse is recognised by the system when disconnected and reconnected but not by X. It also works outside X. I will update the ports tree tonight or tomorrow morning to see what will happen then. Erich On Thu, 9 Jan 2014 11:18:18 -0500 Glen Barber g...@freebsd.org wrote: Changes between -RC4 and -RC5 include: o Fix an IPv4 multicast regression. o Fixes OpenSSL for CVE-2013-4353, CVE-2013-6449, CVE-2013-6450. o Revert a change to the kinfo_file structure to preserve ABI. o Fix a race condition which could prevent the file descriptor table from being properly updated. Rebuild X with the DEVD option instead of HAL. FreeBSD is the only Xorg consumer that did not write their own input device hot plugging ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RTL8111/8168B not negotiating 1GB
On Thu, Jan 2, 2014, at 19:39, Sam Fourman Jr. wrote: Hello list, I have a Asus Sabertooth 990FXv2 motherboard, and a run of the mill NetGear DGS2205 desktop gig switch with linux my Ethernet can negotiate at 1GB but with FreeBSD it can not if I force the device to 1000baseT with ifconfig it does not work. uname -a FreeBSD NewBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r260188M: Thu Jan 2 04:27:49 CST 2014 sfourman@NewBSD:/usr/obj/usr/src/sys/GENERIC amd64 This is probably flying too far off-topic so feel free to ignore me, but this just popped in my head because I ran into this with a pair of Cisco devices recently: On some Cisco gear with certain GBICs / SFPs you can run into a situation where you have a physical link that claims to be up/up but is completely non-functional (no traffic, no mac addresses/arp). The solution is a command that is only available on these interfaces called speed nonegotiate which forces the link to work, bypassing negotiation (simply MDI/MDIX?). I don't know how the low level gigabit auto negotiation magic works or what it fully entails, but I'm wondering if it is something that could be replicated in the FreeBSD drivers/stack. I have a feeling that if it existed and he tried something like ifconfig re0 speed nonegotiate it would not work because he'd need to set that on his switch port as well, but I just thought I'd throw this out there. Here's a link mentioning the feature: http://www.cisco.com/en/US/docs/security/asa/asa70/configuration/guide/intrface.html I'm not sure where to find any true technical details of it, though. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
On Thu, Oct 10, 2013, at 11:26, Alan Somers wrote: Due to popular demand, I have located a round toit. I'm currently working on rebasing the zfsd project branch to head, after which I'll push SpectraLogic's recent changes. Just thought I'd ping the list about the situation here... would love to see this in HEAD soon :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: making PANIC_REBOOT_WAIT_TIME a tunable
On Mon, Dec 2, 2013, at 2:26, Colin Percival wrote: Hi all, It seems that PANIC_REBOOT_WAIT_TIME has been a compile-time setting forever; and I can't see any reason for this, but I assume there was one... at some point in the distant past. The attached patch makes it a loader tunable and sysctl. My reason for wanting this is to make EC2 images reboot faster after a panic (not that it happens very often, of course) -- there's no point waiting for a key press at the console because the EC2 console is output-only. Any objections? I tend to cheat this problem by using watchdog on my hardware servers. This sounds quite convenient as I can't use watchdog in VMs... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Defaults in 10.0 ZFS through bsdinstall
On Fri, Nov 15, 2013, at 3:23, Stefan Esser wrote: Am 14.11.2013 22:02, schrieb Teske, Devin: On Nov 14, 2013, at 12:49 PM, Mark Felder wrote: We don't even do installs on UFS with atime disabled by default in fstab so why should we so suddenly change course for ZFS? You've made a good point. There is major difference between UFS and ZFS: UFS allows in-place updates of i-node fields (like atime), while ZFS uses COW for all data, file contents and meta-data like the i-nodes. With atime ON on UFS you'll see a small number of writes on file-systems that are only read - we are used to accept that. On ZFS every update of atime causes a write of the meta-data to a free location on disk, then updates of all data structures that reference that meta-data up to the root of the tree (the uberblock). An update of a few bytes turns out to write tens of KB for each atime update (within the TXG sync interval, which defaults to 5 seconds on FreeBSD). If you create snapshots, then each snapshot will contain a copy of the metadata that was valid at the time of the snapshot (well, that's not so different from the situation with UFS snapshots, just that the data structures are much more complex and larger in the ZFS case). Due to the ease and speed of snapshot creation with ZFS there probably are a magnitude or more snapshots on a typical ZFS system than on one using UFS (I currently have a few hundred and have turned off periodic snapshot generation on many unimportant file-systems, already). I really hope that we get relatime (with minor variations that were discussed a few months ago) and that we make it the default in some future release ... Thanks for this in-depth explanation. I wasn't aware that atime was quite so expensive on ZFS. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Wed, Nov 6, 2013, at 2:57, Volodymyr Kostyrko wrote: 05.11.2013 20:21, Mark Felder wrote: On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote: On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. So why we shouldn't add something like: 0 * * * * root periodic hourly @reboot root periodic reboot I already do this on some machines to take hourly and boot snapshots with zfSnap. And I think periodic is much better place for such tasks. Submit a PR and a patch and maybe it can slip in to 10.0-RELEASE. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote: On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. This is a good idea. We should do it. How and if this facility gets used is a separate question. Tools, not policy. Support for a cron.d directory is a tool that can be used in many ways. The policy of how it should be used is a separate discussion. (For example, whether or not ports or packages should install crontab files into /usr/local/etc/cron.d/ can be richly debated after that directory exists.) Ok, so we create that directory. Now nobody can use it in a port until FreeBSD 8.4 is EoL -- approximately June 30, 2015. We should be using the existing cron tabs directory *now*. We can't easily force older versions of FreeBSD to update their cron software or configuration to support that new directory. I'm not saying we shouldn't create it, just that we can't effectively use it for 2 years. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: cron(8) improvement
On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote: On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. If the application is installing its own user they could install their own crontab file in /var/cron/tabs. I'm certain I've seen a couple ports do this. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Automated submission of kernel panic reports: sysutils/panicmail
On Mon, Nov 4, 2013, at 20:26, Thomas Mueller wrote: Hi all, After considerable review on freebsd-hackers (thanks dt71 and jilles!) I have now added sysutils/panicmail to the FreeBSD ports tree. If you install this and add panicmail_enable=YES to your /etc/rc.conf, a panic report will be generated and sent to root@ for you to review and submit (via email). You can skip the reviewing step and submit panics automatically by setting panicmail_autosubmit=YES. The panics submitted are encrypted to an RSA key which I hold in order to keep them secure in transit; and I intend to keep the raw panic reports confidential except to the minimum extent necessary for other developers to help me process the incoming reports. If I receive enough panic reports to be useful, I hope to provide developers with aggregate statistics. This may include: * regular email reports listing the top panics, to help guide developers towards the most fertile areas for stability improvements; * email to specific developers alerting them to recurring panics in code they maintain (especially if it becomes clear that the panic has been recently introduced); and * guidance to re@ and secteam@ about how often a particular panic occurs if an errata notice is being considered as well as other yet-to-be-imagined reports of a similarly aggregate and anonymized nature. So please install the sysutils/panicmail port and enable it in rc.conf! This all depends on getting useful data, and I can't do that without your help. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid Question that arises is how does the system know where to send the email, and through what SMTP server, especially if panicmail_autosubmit=YES. Every computer on the planet has the capability of being able to send email directly without an SMTP server. The only question is if the receiving end is willing to accept it, or discard it as spam. In the case of a kernel panic, wouldn't the system crash/freeze, and would it then be able to compose an email message? This is all handled on the next boot after the panic. I use mail/mpop and mail/msmtp rather than messing with sendmail or postfix; have multiple email accounts and inboxes. Does it provide a compatible /usr/sbin/sendmail binary? If so, it will just work^TM. Now come to think of it, I don't think I ever sent an email from FreeBSD as root, only as nonroot. Something like panicmail ought to be ported to NetBSD pkgsrc, considering that NetBSD seems so much more unstable and crash-prone than FreeBSD on my hardware. I hope more projects pick this up too. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Overriding sector size on disks?
On Nov 1, 2013, at 9:45 PM, Adrian Chadd adr...@freebsd.org wrote: Hi! I have an odd problem. That, honestly, can't be that odd. I have a bunch of SATA disks that when plugged into the laptop directly, show up as 512 byte sectors. But if I plug it in via this iomega USB caddy, they show up as 4k sector devices. Because of this, partitions just plainly don't work. Has anyone faced this? Is there some trick to do to get these things to go back to being 512 byte sector devices so one can use them? Similarly, because they show up as 512 byte sector devices on macosx/linux, they can read/write NTFS/MSDOS partitions on the thing. But if I plug it into freebsd, it shows up as a 4k sector device and things plainly don't work. Thanks! My coworker ran into this once. We couldn’t find a workaround. We just noted that we either had to use the disk with the adapter or without — you cannot swap between and expect to read your data. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
On Nov 2, 2013, at 11:54 AM, Adrian Chadd adr...@freebsd.org wrote: You're using a DNS feature which isn't well adopted/supported and you haven't provided a fallback legacy, well tested path. But SRV has been widely deployed since… before 2000? It’s literally the backbone of Active Directory deployments. Here’s a list of things that his company’s network design probably breaks: * Office 365 (cloud Exchange hosting by Microsoft; requires you use SRV records to get your company’s clients pointed to their cloud infrastructure) * LDAP * SIP * XMPP * CALDAV / CARDDAV * SMTP, IMAP, and POP clients should also obey published SRV records. Not sure how many clients really do, though. * Teamspeak 3 doesn’t force you to use SRV, but you can use only SRV records * Minecraft * Last I knew IRCv4 specs are slated to include SRV as a core feature I can’t speak for the caching issues, but SRV is pretty active and only getting more popular because things like “round robin DNS” are a horrible, ugly, unreliable hack and things like Anycast or Geo-DNS isn’t always feasible. -0.02c ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official FreeBSD Binary Packages now available for pkgng
On Nov 2, 2013, at 3:27 PM, Adrian Chadd adr...@freebsd.org wrote: A lot of HTTP infrastructure lives on anycast DNS, HTTP redirects and geoip records. Saying it's broken and not feasible is nonsense. More specifically what I was referring to was the fact that traditionally HTTP failover with round-robin A records is very unreliable; every client can act differently. You really need to be doing anycast as well to ensure those records are always available which adds additional architecture complexity that the project may not have the resources to throw at. GeoDNS also adds a layer of complexity, but as it turns out there are members of the project with extensive experience running it. SRV would give us very simple, cheap, reliable failover. It seems we do have some blockers, though. The good news is that we fully control the client. Hopefully we can just work around these issues. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: hwpstate0: set freq failed patch
On Tue, Oct 29, 2013, at 9:27, Claudio Zumbo wrote: Hello, Would it be possible for this patch to get to 10 before it goes -release? http://lists.freebsd.org/pipermail/freebsd-stable/2012-May/067758.html I've tested it on an amd 6600k and it seems to be working, a quick google search shows other people have had good results on different cpus. I saw you in #bsddev this morning. PR in question: http://www.freebsd.org/cgi/query-pr.cgi?pr=167018 CCing hiren@ and avg@ I have no idea if this can make it in 10, but we're still in BETA. It would be nice if powerd worked out of the box on those chips. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On Wed, Oct 23, 2013, at 19:11, Adrian Chadd wrote: On 23 October 2013 15:31, Vincent Hoffman vi...@unsane.co.uk wrote: On 23/10/2013 18:35, Eitan Adler wrote: On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd adr...@freebsd.org adr...@freebsd.org wrote: If there are drivers that people absolutely need fixed then they should stand up and say hey, I really would like X to work better! and then follow it up with some encouraging incentives. Right now the NDISulator lets people work _around_ this by having something that kind of works for them but it doesn't improve our general driver / stack ecosystems. I doubt most people prefer to use the ndisulator over a native driver. However, many people don't have the skills, time, or money to provide the incentives you are talking about. At this point ndisulator provides a means to an end: working wireless and it isn't causing significant strain on the project in terms of development effort. Our end users are not always developers and I think removing this feature will hurt more than it will help. As an end user, the main issue I have is that according to the manpage it supports ndis 5.1 According to http://en.wikipedia.org/wiki/Network_Driver_Interface_Specification this is the version supported by Windows XP http://en.wikipedia.org/wiki/Windows_XP, Server 2003http://en.wikipedia.org/wiki/Windows_Server_2003, Windows CE http://en.wikipedia.org/wiki/Windows_CE 4.x, 5.0, 6.0 As you might guess most new devices wont be coming with drivers for XP, so does this mean I wont be able to use drivers for a recent windows version (my understanding is that it will but happy to learn differently) If this is the case and there is no active development on it, a gradual depreciation over the 10.x series is probably a good idea. If however its likely to support current drivers/devices it does have a place (I've used it once or twice in a pinch.) This is why I'd rather us bite the bullet now and deprecate it, versus have it in there and put in the work to upgrade it to handle NDIS 6.x drivers with the Microsoft wireless extensions stuff. 802.11AC adapters claiming Windows XP support: (very quick search) http://www.asus.com/Networking/USBAC53/ http://www.asus.com/Networking/PCEAC66/ http://www.netgear.com/home/products/wireless-adapters/ultimate-wireless-adapters/A6200.aspx#two http://www.trendnet.com/products/proddetail.asp?prod=100_TEW-805UBcat=202 If these idiots would quit making drivers for XP you might have an easier battle ahead, Adrian. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
Is there any harm in marking it as deprecated in 10 so awareness begins immediately? We can delay its removal beyond 11 if absolutely necessary... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: May you please add alias for nslookup?
On Sat, Oct 12, 2013, at 11:34, Julian H. Stacey wrote: RW wrote: On Sat, 12 Oct 2013 10:44:56 +0200 Ivan Voras wrote: explaning the user what has happened and optionally invoking host or dig. Actually dig has gone Rather cryptic for me so I looked: dig has gone from current src/usr.bin/dig nslookup dig host are all installed by either of current ports/dns/bind99 or ports/dns/bind-tools and has been replaced by the unbound utility drill. src/usr.bin/drill/ I agree with O.P. Zhifeng Hu's this is a very basic tools. Removing src/contrib/bind9 from FreeBSD-10 will get criticised as: Calls itself a server OS, but no name server out of the box! Please resist periodic urges to strip src/ towards just a tool set capable of rebuilding itself. Tossing expected tools (even if a port is more up to date secure) will annoy users, potential immigrants from other Unixes may try then toss FreeBSD. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. I don't think anyone can explain this better than the last post DES put on his blog about it http://blog.des.no/2013/09/dns-again-a-clarification/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote: On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks joh.hendr...@gmail.com wrote: When i started using ZFS on FreeBSD I quickly found out that hot spares are not possible on FreeBSD. I was told that with zfsd it should be possible and that it would be included in FreeBSD 10. Is there some info about the zfsd function and how it could be used? zfsd is currently not in FreeBSD/head and won't make it into 10, but you can still get the source code from its project branch. It's being used in production by at least two companies. So FreeBSD is going to have inferior ZFS management compared to Solaris/Illumos/etc for another 2+ years? Why are things like this allowed to miss releases? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
On Thu, Oct 10, 2013, at 12:40, Allan Jude wrote: On 2013-10-10 13:26, Alan Somers wrote: On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude free...@allanjude.com wrote: On 2013-10-10 12:13, Mark Felder wrote: On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote: On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks joh.hendr...@gmail.com wrote: When i started using ZFS on FreeBSD I quickly found out that hot spares are not possible on FreeBSD. I was told that with zfsd it should be possible and that it would be included in FreeBSD 10. Is there some info about the zfsd function and how it could be used? zfsd is currently not in FreeBSD/head and won't make it into 10, but you can still get the source code from its project branch. It's being used in production by at least two companies. So FreeBSD is going to have inferior ZFS management compared to Solaris/Illumos/etc for another 2+ years? Why are things like this allowed to miss releases? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3 weeks ago). There is a lot of collaboration going on, to bring in some work done by vendors like SpectraLogics. This is the type of feature that can be assed in 10.1, it won't have to wait for 11. You can see Robert Watsons talk How FreeBSD Works to see why releases are based on date, rather than on feature completion (because things are never finished) -- Allan Jude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Due to popular demand, I have located a round toit. I'm currently working on rebasing the zfsd project branch to head, after which I'll push SpectraLogic's recent changes. See, all you have to do is complain loudly enough :p I was sad more than anything. I'd been waiting for zfsd since the project was announced. :-) I'm glad to know we won't have to wait until 11.0. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rcs
On Tue, Oct 8, 2013, at 10:33, Alfred Perlstein wrote: Oh I have done that in the past, but why the editing, the makefiles, the etc, etc, etc. Why isn't there a customize.freebsd.org where I just hit a few checkboxes, save and then hit download? A metaport builder web service would be really slick, actually... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD Alpha5 amd64 - Citrix Xen 6.2 problem
On Tue, Oct 8, 2013, at 9:45, Josias L.G wrote: Problem with Citrix Xen 6.2 and install from ISO. The solution was remove cd-rom drive from virtual machine. Not possible now with xen default in GENERIC kernel. Message error: run_interrupt_driven_hooks - still waiting after 300 seconds for xenbusb_nop_confighook_cb panic: run_interrupt_driven_config_hooks: waited too long I was going to test this soon... but you're right -- you probably can't install FreeBSD 10 from ISO on Citrix XenServer because of this bug. Can someone working on the xen bits test and maybe find a workaround? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS L2ARC - incorrect size and abnormal system load on r255173
On Mon, Oct 7, 2013, at 13:09, Dmitriy Makarov wrote: How can L2 ARC Size: (Adaptive) be 1.44 TiB (up) with total physical size of L2ARC devices 490GB? http://svnweb.freebsd.org/base?view=revisionrevision=251478 L2ARC compression perhaps? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CURRENT] unbound: zonefiles?
On Thu, Sep 26, 2013, at 4:26, O. Hartmann wrote: I try my first steps with unbound on most recent current and snealing through the web I find interesting things and howto's. But I realise if I'd like to replace my office's DNS server (based on BIND as it was part of the FreeBSD world) I run into a serious problem regarding the zone- and authorative files keeping all the PTR and A records. As I can see in the unbound.conf, the statements of those files (address to name resolution, name to address resolution) is now somehow hard coded into unbound.conf via those appropriate config tags like local-zone and local-data. Since I have some larger files defining a local domain, I'd expect having a data file to be loaded. Unbound exists as a project to be a very fast, lightweight, and secure DNS *recursor*. It is not meant to be authoritative for DNS zones; it's for caching lookups only. However, they did include the ability for you to manually configure zones/records in its config file but it's not very robust. I use it to set a single static record on my LAN, but it is of no use to the outside world. If I opened it to the outside world I'd just end up with an open DNS resolver which is a very bad idea. (openresolvers.org) BIND functioned as both roles. The lack of separation is often why it is criticized. DJB made the separation of roles famous when he released DJBDNS which includes two daemons: dnscache and tinydns. The complementary daemon by the Unbound authors (NLNet Labs) is called nsd. This is probably what you're looking for. Please keep in mind you cannot run both nsd and unbound on the same IP as they both cannot listen on the same port (53). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CURRENT] unbound: zonefiles?
On Mon, Sep 30, 2013, at 8:53, Dimitry Andric wrote: On Sep 30, 2013, at 14:28, Mark Felder f...@freebsd.org wrote: ... BIND functioned as both roles. The lack of separation is often why it is criticized. DJB made the separation of roles famous when he released DJBDNS which includes two daemons: dnscache and tinydns. The complementary daemon by the Unbound authors (NLNet Labs) is called nsd. This is probably what you're looking for. Please keep in mind you cannot run both nsd and unbound on the same IP as they both cannot listen on the same port (53). Yes, and there is the rub for most 'SOHO' users, who do not win anything by separating these roles. In such cases, setting up a separate IP and/or port just to split up authoritative and recursive DNS is rather inconvenient... We should update the handbook to point people to the version of BIND in ports. We can't keep BIND 9 in base forever, and BIND 10 would require we import Python... We don't have a lot of options at this point and DES pointed out in his blog that the future of DNS is in base is being reworked for FreeBSD 11. This is just a stopgap. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: OpenSSH with DNSSEC support in 10
On Wed, Sep 11, 2013, at 11:16, Ian Lepore wrote: Thanks. If this is client-side I'm much less scared by it. At $work we have embedded systems with less than full network functionality, often including either /etc/hosts usage or worse, sometimes a dns is configured but unreachable, and we ssh into them a lot for development. Do you work around that problem by setting UseDNS no? We have that pretty much standard on all our servers at work because if you ssh and both client and server have ipv6 the connection takes forever for it to give up trying to find a PTR for your client's ipv6 address. And don't try to use GENERATE in BIND to make PTRs for all your ipv6 addresses... you'll run out of memory trying to start the daemon :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw
On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Linux epoll(7) patch
On Mon, Aug 5, 2013, at 10:22, Alfred Perlstein wrote: The patch is small. I too am wondering why it's not committed, was there any push back? The glory days of the Linuxulator were around FreeBSD 6 when basically everything ran and often it ran much faster. We could really use a revival of this with the FreeBSD 10 release... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Linux epoll(7) patch
On Mon, Aug 5, 2013, at 10:36, Sam Fourman Jr. wrote: epoll is needed to get the linux version of plex media server working in FreeNAS, however in the last month or so it looks as if a FreeBSD native app has been released I'm working closely with Elan (head of Plex) and expect to be committing a port to the tree soon. You can test the port here: https://github.com/felderado/plexmediaserver_port/ I believe the FreeBSD version at this time lacks the ability to auto-detect filesystem changes so manual scanning or notification from your download software will be required. Sickbeard and Couch Potato can do this, for example. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ports with daemons on uninstall...
On Sun, Jul 14, 2013, at 14:49, Garrett Wollman wrote: Strongly agreed -- and it's what other operating systems do, either by policy or by convention. As long as this behavior only happens during pkg installs and never with ports, I'm OK. The worst is when a coworker forgets that the mysql port stops the daemon and my coworker upgrades with portmaster... the daemon is off the entire time mysql slowly compiles... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ports with daemons on uninstall...
On Mon, Jul 15, 2013, at 8:44, RW wrote: Is that really correct? I would expect the deinstall to be done after the build has completed successfully. That might not be accurate with a current portmaster, but we used to have that happen all too frequently. I just checked the plist and it has @stopdaemon mysql-server, so I'm guessing portmaster would run that too prematurely. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] No more pkg_install on HEAD by default
On Mon, 15 Jul 2013 11:48:18 -0500, Teske, Devin devin.te...@fisglobal.com wrote: I think Mark was saying that libfetch doesn't yet support http proxy. Now that I've googled, I was referring to this PR http://www.freebsd.org/cgi/query-pr.cgi?pr=180253 I thought it was complete missing functionality, not just that bug. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] No more pkg_install on HEAD by default
On Sat, Jul 13, 2013, at 13:54, Teske, Devin wrote: If FTP access (or any of the other remote access methods) are going away for HEAD pkg access, I'll need to know so I can make the appropriate changes in the HEAD branch of bsdconfig. It's simpler than you think. The new pkg uses libfetch. You can have your PACAKGESITE be file:// ftp:// http:// https:// ... I do suspect that HTTP_PROXY support is probably not available as I recall seeing a post where someone was asking about that getting implemented for fetch. I'll have to research that again, though. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_addrs_IF aliases in rc.conf(5)
On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm trash...@odo.in-berlin.de wrote: Will that patch make it into 9.2? If I am not mistaken, that patch isn't in stable yet. I would also like to see this patch hit 9.x sooner than later. It's so painful when someone forgets to fix the alias numbering on servers with many, many IPv4 and IPv6 addresses... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: chroots/jails in jails
On Tue, 09 Jul 2013 07:21:40 -0500, Julian Elischer jul...@freebsd.org wrote: seems like there should be someone out there who has hit this.. (and solved it?) Poudriere can itself be run in a jail... does it do hierarchical jails? I've never tested it myself. Bapt's loose documentation of it is here: https://fossil.etoilebsd.net/poudriere/doc/trunk/doc/poudriere_in_jail.wiki ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: devd or dhclient or ifconfig behavior seems broken
Check the man page for dhclient.conf. You can use the supercede functionality to always force the settings you prefer. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Zoneminder build failure
On Sun, 30 Jun 2013 16:19:48 -0500, Saul A. Peebsen jaglo...@gmail.com wrote: Running -CURRENT, I'm getting this: c++ -O2 -pipe -march=core2 -fno-strict-aliasing -L/usr/local/lib -L/usr/local/lib/mysql -lpthread -o zmc zmc.o zm_box.o zm_buffer.o zm_camera.o zm_comms.o zm_config.o zm_coord.o zm.o zm_db.o zm_logger.o zm_event.o zm_exception.o zm_file_camera.o zm_ffmpeg_camera.o zm_image.o zm_jpeg.o zm_local_camera.o zm_monitor.o zm_ffmpeg.o zm_mpeg.o zm_poly.o zm_regexp.o zm_remote_camera.o zm_remote_camera_http.o zm_remote_camera_rtsp.o zm_rtp.o zm_rtp_ctrl.o zm_rtp_data.o zm_rtp_source.o zm_rtsp.o zm_sdp.o zm_signal.o zm_stream.o zm_thread.o zm_time.o zm_timer.o zm_user.o zm_utils.o zm_zone.o -lz -lbz2 -lswscale -lavdevice -lavformat -lavcodec -lavutil -lz -lpcre -lcrypto -lc -lpthread -ljpeg -lmysqlclient zm_timer.o: In function `Timer::TimerThread::run()': zm_timer.cpp:(.text+0x428): undefined reference to `ThreadDatabool::setValue(bool)' c++: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Is there a fix for it? I haven't had a chance to look at that port or build it recently, but is it being built by CLANG on current? If so, is it fixed if you tell it to build with GCC? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: Unrecoverable machine check exception
Pretty sure the cause of this was User error: CPU too hot. Please don't waste your time on it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: Unrecoverable machine check exception
I'm trying to get my server to a stable build of current so I can run a current poudriere jail alongside my 9.1 and 8.4 environments for testing package building. This server runs several other jails that host all the other services on my server. Coredump, etc can be found here: http://feld.me/freebsd/r251046/ Any suggestions on how to work around this so I can stabilize my build server would be appreciated. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Cannot startx on FreeBSD10 Current
On Fri, 14 Jun 2013 10:56:26 -0500, Miguel Clara miguelmcl...@gmail.com wrote: I still have some problems though... I can't switch to console with CRTL+ALT+F1...2..3... etc I get a very weired screen, like my kde all nuts... the good thing is I can at least switch back to kde. I also noted that at shutdown/reboot I get a black screen nothing shows on screen, I just have to wait for it to turn off... I get the feeling that this is somehow related! With KMS you can't get to a tty after it's running. That's known errata, so once you start X you can't leave it without a reboot. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Cannot startx on FreeBSD10 Current
On Fri, 14 Jun 2013 11:11:17 -0500, Miguel Clara miguelmcl...@gmail.com wrote: Is this something that will be fixed anytime soon? What about the black screen on reboot? Is that normal? That is also the same issue -- once you start KMS you can't get a tty back, which is what would happen with other video drivers when you kill X as part of the reboot process. I believe this is considered low priority right now, but it will eventually behave properly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Cannot startx on FreeBSD10 Current
On Fri, 14 Jun 2013 12:05:13 -0500, Miguel Clara miguelmcl...@gmail.com wrote: I wouldn't consider having no visual output from a laptop when you reboot/shutdown low priority... But that's not for me to decide... in any case is there any Bug Report/PR open about this that we can follow up? I would like to keep up to date with this. The driver is still in heavy development and considered incomplete, so there is no PR. Keep an eye on this Wiki page, and note the FAQ at the bottom: https://wiki.freebsd.org/Intel_GPU ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: request for your comments on release documentation
On Wed, 12 Jun 2013 12:49:21 -0500, Hiroki Sato h...@freebsd.org wrote: So, my questions are: 1. What do you think about current granularity of the relnotes items? Too detailed, good, or too rough? Currently, judgment of what is included or not is based on user-visible, new functionality, or performance improvement. Applicable changes are included as relnotes items even if the changes are small, As a sysadmin I live and die by the granularity of release notes. If they weren't granular I'd end up having to read the commit logs and try to parse out changes myself. Sometimes changes aren't going to be obvious if you weren't aware of discussions on the -hackers, -current, or -stable lists. 2. Do you want technical details? For example, just disk access performance was improved by 50% or Feature A has been added. This changes the old behavior because ..., and as a result, it improves disk access performance by 50%. I'm sure if you're too terse like in your first example people will jump to conclusions and be angry when disk performance isn't improved 50% in every possible situation, as well as the project receiving bad press for being too deceiving. If you want to be terse perhaps Disk access improvements is sufficient, and use the second example if you want to be more explicit. 3. Is there missing information which should be in the relnotes? Probably there are some missing items for each release, but this question is one at some abstraction level. Link to commit log and diff, detailed description of major incompatible changes, and so on. I try to keep up with the development and changes in releases as best I can and I haven't noticed any glaring omissions over the last several releases. I think you're doing a fine job. Also, is there a reason this isn't a living document that can be updated as things get MFC'd to STABLE? It would help take load off your end and maybe speed up release once the freeze has happened and we begin the final grind through release candidates. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Light humour
On Mon, 29 Apr 2013 12:43:41 -0500, Bernd Walter ti...@cicely7.cicely.de wrote: Want to know link states use some strange tools. This has been my complaint for ages. Task / BSD / Linux set ip / ifconfig / ifconfig or now ip which is extremely confusing wifi / ifconfig / iwconfig speed / ifconfig / miitool or ethtool duplex / ifconfig / miitool or ethtool vlan / ifconfig / vlan wol / ifconfig / miitool or ethtool bridge / ifconfig / brctl link aggregation / ifconfig / flags while loading module OR use distro network config scripts and restart *all* networking or reboot server!!! Zero guidelines or direction in their projects. It's even more painful when you install a distro and need to set vlan or duplex and you can't because the utility needs to be installed from the repository. Not sure if that's still commonplace but I was bit by it several times with debian installs. BSD has its own problems, but code quality and the thought put into design seems to be taken into serious consideration before something is committed to HEAD. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipv6_addrs_IF aliases in rc.conf(5)
I would also like to see this committed. I started on my own patch about 4 months ago but got sidetracked. This would be very, very valuable to the sysadmins at my workplace. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Response of *.freebsd.org websites are very slow
On Wed, 27 Feb 2013 06:52:29 -0600, fb...@a1poweruser.com wrote: Well I am in cleveland ohio usa and I have noticed that http://www.freebsd.org/handbook/ is slow or in most cases just times out. So this is bigger problem that some mirror being down in turkey. It started about 10 days ago. I can't reproduce this myself. Can you provide a traceroute? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Response of *.freebsd.org websites are very slow
On Wed, 27 Feb 2013 07:13:27 -0600, fb...@a1poweruser.com wrote: traceroute www.freebsd.org Here's mine going to the same destination without issue. # traceroute www.freebsd.org traceroute to wfe0.ysv.freebsd.org (8.8.178.110), 64 hops max, 52 byte packets 1 192.168.93.1 (192.168.93.1) 0.494 ms 0.472 ms 0.459 ms 2 vl80-vrrp.switch01.excelsior.supranet.net (66.170.8.3) 0.804 ms 0.734 ms 0.950 ms 3 r3-em0.excelsior.supranet.net (66.170.0.138) 0.775 ms 0.753 ms 0.755 ms 4 vlan607.car2.chicago2.level3.net (4.26.46.169) 7.195 ms 6.638 ms 7.244 ms 5 ae-1-51.edge3.chicago3.level3.net (4.69.138.136) 6.590 ms 6.299 ms 6.304 ms 6 gblx-level3-10g.chicago3.level3.net (4.68.62.202) 5.991 ms gblx-level3-10g.chicago3.level3.net (4.68.63.66) 6.216 ms 7.515 ms 7 xe9-1-2-10g.scr4.snv2.gblx.net (67.16.160.34) 54.299 ms ae14.scr4.snv2.gblx.net (67.16.164.153) 54.490 ms 55.534 ms 8 e5-3-40g.ar5.sjc2.gblx.net (67.17.72.14) 69.572 ms 60.789 ms 55.438 ms 9 yahoo-san-jose.tengig2-3.1189.ar3.sjc2.gblx.net (64.211.206.210) 57.978 ms yahoo.tengigabitethernet2-4.1189.ar3.sjc2.gblx.net (208.48.239.254) 56.148 ms yahoo-san-jose.tengig2-3.1189.ar3.sjc2.gblx.net (64.211.206.210) 57.467 ms 10 ae-4.pat1.sjc.yahoo.com (216.115.105.16) 58.248 ms 58.448 ms routerer-ext.freebsd.org (216.115.101.225) 59.220 ms 11 wfe0.ysv.freebsd.org (8.8.178.110) 58.955 ms routerer-ext.freebsd.org (216.115.101.225) 59.339 ms wfe0.ysv.freebsd.org (8.8.178.110) 59.474 ms So you can't get past the first hop? Are you blocking ICMP anywhere? Because that will destroy PMTU-D and cause all kinds of havoc. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Response of *.freebsd.org websites are very slow
On Wed, 27 Feb 2013 07:39:40 -0600, fb...@a1poweruser.com wrote: Lets change the test from traceroute to pointing your browser at www.freebsd.org and see what your response time is if at all. Screenshots showing latency via Chromium's developer tools: http://i.imgur.com/DaSNc6b.png http://i.imgur.com/pvXEGgo.png ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PathScale EKO Path 5 not for FreeBSD anymore?
I've been talking to others and it seems that several of us are convinced that BSD is back on the uptake, so I wouldn't be so quick to mark its demise. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Hardware VM support for Jails
On Mon, 14 Jan 2013 06:18:34 -0600, cede...@tlen.pl wrote: Hello :-) I was wondering if there is a hardware accelerated Jail using Virtualization CPU extensions in BSD or everything is done in Kernel by software? SUSE is advertising their light virtualization (no hardware emulation) I was wondering if BSD has this capabilities too ;-) What would be benefit for this over Jail? The jails don't need to use these CPU extensions because jails are just like running the native OS. There really aren't any abstraction layers hindering performance. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD development audio system: KLANG
On Mon, 13 Aug 2012 09:57:21 +0300 Volodymyr Kostyrko c.kw...@gmail.com wrote: 2. It's claiming very spurious tasks like adding full audio routing support like JACK does. I personally think that most users doesn't need it and I can't really say who and how will benefit of this. Full audio routing isn't needed, but I'd be satisfied if there was some way to specify that my USB Microphone is my default input and my sound card is my default output. This isn't possible in the current OSS implementation (can only choose default device which takes over /dev/dsp completely), but other than that FreeBSD has the best audio system in a *nix right now. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DragonFly vs FreeBSD scheduler
On Sat, 3 Nov 2012 21:18:55 +0800 Alie Tan a...@affle.com wrote: Hi, No offence, just curious about scheduler and its functionality. What is the different between this two that makes FreeBSD performance far behind DragonFly BSD? http://www.dragonflybsd.org/release32/ I don't have any details but I do know that Dragonfly has been putting a lot of work into their scheduler. Hopefully some of that will trickle back our way. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
