Re: GOST in OPENSSL_BASE

2016-07-11 Thread Mark Felder


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

2016-07-06 Thread Mark Felder


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

2016-06-16 Thread Mark Felder
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

2015-12-10 Thread Mark Felder


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

2015-11-10 Thread Mark Felder


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  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

2015-11-04 Thread Mark Felder


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

2015-11-03 Thread Mark Felder
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"


Re: pkg with an ssh repo crashes CURRENT

2015-08-24 Thread Mark Felder


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: RCTL and VIMAGE for 11.0-RELEASE

2015-08-24 Thread Mark Felder


On Mon, Aug 24, 2015, at 14:18, Bjoern A. Zeeb wrote:
> > On 24 Aug 2015, at 19:08 , Mark Felder  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=282900&r2=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"

RCTL and VIMAGE for 11.0-RELEASE

2015-08-24 Thread Mark Felder
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: pkg with an ssh repo crashes CURRENT

2015-08-20 Thread Mark Felder


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

2015-08-20 Thread Mark Felder


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:
neti

Re: pkg with an ssh repo crashes CURRENT

2015-08-19 Thread Mark Felder
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"


pkg with an ssh repo crashes CURRENT

2015-08-19 Thread Mark Felder
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: Turbulence in head @r282676.

2015-05-11 Thread Mark Felder


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

2015-03-17 Thread Mark Felder


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: sbuf-related panic

2015-03-17 Thread Mark Felder


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: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"

2015-02-23 Thread Mark Felder


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.*)

2015-01-28 Thread Mark Felder


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?

2014-11-11 Thread Mark Felder


On Tue, Nov 11, 2014, at 13:16, Dimitry Andric wrote:
> On 11 Nov 2014, at 04:28, Mark Felder  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?

2014-11-10 Thread Mark Felder


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

2014-08-26 Thread Mark Felder
August 26 2014 2:49 PM, "Garrett Cooper"  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: FreeBSD 10 and zfsd

2014-08-26 Thread Mark Felder
August 26 2014 2:45 PM, "Alan Somers"  wrote: 
> On Tue, Aug 26, 2014 at 1:39 PM, Mark Felder  wrote:
> 
>> August 26 2014 10:21 AM, "Alan Somers"  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

2014-08-26 Thread Mark Felder
August 26 2014 10:21 AM, "Alan Somers"  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

2014-08-26 Thread Mark Felder
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: Future of pf / firewall in FreeBSD ? - does it have one ?

2014-08-01 Thread Mark Felder
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 ?

2014-07-26 Thread Mark Felder
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 ?

2014-07-24 Thread Mark Felder

> On Jul 24, 2014, at 13:43, Mark Felder  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 ?

2014-07-24 Thread Mark Felder

> On Jul 23, 2014, at 15:59, Bjoern A. Zeeb  
> 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 ?

2014-07-19 Thread Mark Felder

On Jul 19, 2014, at 3:35, Andreas Nilsson  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 ?

2014-07-18 Thread Mark Felder
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

2014-06-27 Thread Mark Felder
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

2014-06-02 Thread Mark Felder

On 2014-06-02 07:05, M&S - 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

2014-05-30 Thread Mark Felder

On May 28, 2014, at 9:54, John Baldwin  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

2014-05-12 Thread Mark Felder

On Apr 17, 2014, at 3:21, David Chisnall  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

2014-03-25 Thread Mark Felder

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?

2014-03-24 Thread Mark Felder

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

2014-03-23 Thread Mark Felder
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

2014-03-06 Thread Mark Felder


On Thu, Mar 6, 2014, at 11:28, Lowell Gilbert wrote:
> Glen Barber  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: reproducible panic every day at 03:02, probably triggered by daily periodic scipts - help

2014-03-06 Thread Mark Felder


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: Import of DragonFly Mail Agent

2014-02-25 Thread Mark Felder


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

2014-02-24 Thread Mark Felder


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: Import of DragonFly Mail Agent

2014-02-24 Thread Mark Felder


On Mon, Feb 24, 2014, at 9:50, Lyndon Nerenberg wrote:
> 
> On Feb 24, 2014, at 7:40 AM, Bryan Drewery  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

2014-02-24 Thread Mark Felder
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

2014-02-24 Thread Mark Felder
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 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.
> >>
> >> 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: Apple Trackpad driver

2014-01-29 Thread Mark Felder


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

2014-01-25 Thread Mark Felder


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

2014-01-24 Thread Mark Felder
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

2014-01-16 Thread Mark Felder
On Wed, Jan 15, 2014, at 23:11, Tim Kientzle wrote:
> 
> On Jan 14, 2014, at 6:47 AM, Mark Felder  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

2014-01-14 Thread Mark Felder
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

2014-01-11 Thread Mark Felder
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  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

2014-01-02 Thread Mark Felder
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

2013-12-18 Thread Mark Felder
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

2013-12-04 Thread Mark Felder


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

2013-11-15 Thread Mark Felder


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

2013-11-06 Thread Mark Felder


On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote:
> 
> On Nov 5, 2013, at 9:31 AM, 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.
> 
> 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

2013-11-06 Thread Mark Felder
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

2013-11-05 Thread Mark Felder


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

2013-11-04 Thread Mark Felder


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: Official FreeBSD Binary Packages now available for pkgng

2013-11-02 Thread Mark Felder

On Nov 2, 2013, at 3:27 PM, Adrian Chadd  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: Official FreeBSD Binary Packages now available for pkgng

2013-11-02 Thread Mark Felder

On Nov 2, 2013, at 11:54 AM, Adrian Chadd  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: Overriding sector size on disks?

2013-11-02 Thread Mark Felder

On Nov 1, 2013, at 9:45 PM, Adrian Chadd  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: hwpstate0: set freq failed patch

2013-10-29 Thread Mark Felder
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

2013-10-23 Thread Mark Felder
On Wed, Oct 23, 2013, at 19:11, Adrian Chadd wrote:
> On 23 October 2013 15:31, Vincent Hoffman  wrote:
> 
> >  On 23/10/2013 18:35, Eitan Adler wrote:
> >
> > On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd  
> >  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 , Server 
> > 2003,
> > 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-805UB&cat=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

2013-10-21 Thread Mark Felder
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?

2013-10-12 Thread Mark Felder
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

2013-10-10 Thread Mark Felder


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  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 
> >>>> 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: FreeBSD 10 and zfsd

2013-10-10 Thread Mark Felder
On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote:
> On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks 
> 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 Alpha5 amd64 - Citrix Xen 6.2 problem

2013-10-08 Thread Mark Felder
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: rcs

2013-10-08 Thread Mark Felder
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: ZFS L2ARC - incorrect size and abnormal system load on r255173

2013-10-07 Thread Mark Felder
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=revision&revision=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?

2013-09-30 Thread Mark Felder
On Mon, Sep 30, 2013, at 8:53, Dimitry Andric wrote:
> On Sep 30, 2013, at 14:28, Mark Felder  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: [CURRENT] unbound: zonefiles?

2013-09-30 Thread Mark Felder
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: HEADS UP: OpenSSH with DNSSEC support in 10

2013-09-11 Thread Mark Felder
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

2013-08-23 Thread Mark Felder
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

2013-08-05 Thread Mark Felder
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: Linux epoll(7) patch

2013-08-05 Thread Mark Felder
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: [HEADSUP] No more pkg_install on HEAD by default

2013-07-15 Thread Mark Felder
On Mon, 15 Jul 2013 11:48:18 -0500, Teske, Devin
 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: Ports with daemons on uninstall...

2013-07-15 Thread Mark Felder
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: Ports with daemons on uninstall...

2013-07-15 Thread Mark Felder
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: [HEADSUP] No more pkg_install on HEAD by default

2013-07-13 Thread Mark Felder
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)

2013-07-10 Thread Mark Felder
On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm  
 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

2013-07-09 Thread Mark Felder
On Tue, 09 Jul 2013 07:21:40 -0500, Julian Elischer   
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

2013-07-04 Thread Mark Felder
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: panic: Unrecoverable machine check exception

2013-07-01 Thread Mark Felder
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"


Re: Zoneminder build failure

2013-07-01 Thread Mark Felder
On Sun, 30 Jun 2013 16:19:48 -0500, Saul A. Peebsen   
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
`ThreadData::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"


panic: Unrecoverable machine check exception

2013-06-29 Thread Mark Felder
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

2013-06-14 Thread Mark Felder
On Fri, 14 Jun 2013 12:05:13 -0500, Miguel Clara   
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: Cannot startx on FreeBSD10 Current

2013-06-14 Thread Mark Felder
On Fri, 14 Jun 2013 11:11:17 -0500, Miguel Clara   
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

2013-06-14 Thread Mark Felder
On Fri, 14 Jun 2013 10:56:26 -0500, Miguel Clara   
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: request for your comments on release documentation

2013-06-12 Thread Mark Felder

On Wed, 12 Jun 2013 12:49:21 -0500, Hiroki Sato  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

2013-04-29 Thread Mark Felder
On Mon, 29 Apr 2013 12:43:41 -0500, Bernd Walter   
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)

2013-04-14 Thread Mark Felder
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

2013-02-27 Thread Mark Felder

On Wed, 27 Feb 2013 07:39:40 -0600,  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: Response of *.freebsd.org websites are very slow

2013-02-27 Thread Mark Felder

On Wed, 27 Feb 2013 07:13:27 -0600,  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

2013-02-27 Thread Mark Felder

On Wed, 27 Feb 2013 06:52:29 -0600,  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: PathScale EKO Path 5 not for FreeBSD anymore?

2013-02-20 Thread Mark Felder
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

2013-01-14 Thread Mark Felder

On Mon, 14 Jan 2013 06:18:34 -0600,  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

2012-12-03 Thread Mark Felder
On Mon, 13 Aug 2012 09:57:21 +0300
Volodymyr Kostyrko  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

2012-11-03 Thread Mark Felder
On Sat, 3 Nov 2012 21:18:55 +0800
Alie Tan  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"


  1   2   >