Re: r273910 build failure if is out-of-date

[Beeblebrox]

I was just curious and decided to try an i386 build:
# make -C /usr/src buildworld TARGET=i386 -DNO_CCACHE
Gives same error:

/asp/git/src/lib/libc/../../include/semaphore.h:41:16: error: field has 
incomplete type 'struct _usem2'

struct _usem2   _kern;  ^
/asp/git/src/lib/libc/../../include/semaphore.h:41:9: note: forward 
declaration

of 'struct _usem2'
struct _usem2   _kern;   ^
cancelpoints_sem_new.c:66:33: error: use of undeclared identifier 
'USEM_MAX_COUNT'
_Static_assert(SEM_VALUE_MAX <= USEM_MAX_COUNT, "SEM_VALUE_MAX too 
large");^
cancelpoints_sem_new.c:335:15: warning: implicit declaration of function 
'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration]

*sval = (int)USEM_COUNT(sem->_kern._count);   ^
cancelpoints_sem_new.c:342:23: error: use of undeclared identifier 
'UMTX_OP_SEM2_WAKE'

return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL);   ^
cancelpoints_sem_new.c:361:23: error: use of undeclared identifier 
'UMTX_OP_SEM2_WAIT'

return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0,^
cancelpoints_sem_new.c:445:14: error: use of undeclared identifier 
'USEM_HAS_WAITERS'

if (count & USEM_HAS_WAITERS)
___
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"

Jenkins build is back to normal : FreeBSD_HEAD-tests2 #177

[jenkins-admin]

See 

___
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: missing nullmailer feature in dma(8)/dmagent

[Harald Schmalzbauer]

 Bezüglich Harald Schmalzbauer's Nachricht vom 28.10.2014 17:54
(localtime):
>  Bezüglich Baptiste Daroussin's Nachricht vom 28.10.2014 17:44 (localtime):
> …
>> The NULLCLIENT feature should exactly be what you are looking for, no?
>> As written in the manpage:
>>
>> 
>> Bypass aliases and local delivery, and instead forward all mails to
>> the defined `SMARTHOST'.  `NULLCLIENT' requires `SMARTHOST' to be
>> set.
>> 
> Doh… should try harder getting more sleep ;-)
> Sorry for the noise, seems indeed to be exactly what I was looking for.
> Can't explain why I missed that, thanks!

Ahh, now I can explain ;-)
It's the port's version (v0.9_1,1) which lacks this feature.
I saw on github that you added this functionality in February 2014, but
VERSION wasn't bumped since June 2013.
So I guess the port does checkout an outdated version?

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: missing nullmailer feature in dma(8)/dmagent

[Baptiste Daroussin]

On Mon, Nov 03, 2014 at 12:52:04PM +0100, Harald Schmalzbauer wrote:
>  Bezüglich Harald Schmalzbauer's Nachricht vom 28.10.2014 17:54
> (localtime):
> >  Bezüglich Baptiste Daroussin's Nachricht vom 28.10.2014 17:44 (localtime):
> > …
> >> The NULLCLIENT feature should exactly be what you are looking for, no?
> >> As written in the manpage:
> >>
> >> 
> >> Bypass aliases and local delivery, and instead forward all mails to
> >> the defined `SMARTHOST'.  `NULLCLIENT' requires `SMARTHOST' to be
> >> set.
> >> 
> > Doh… should try harder getting more sleep ;-)
> > Sorry for the noise, seems indeed to be exactly what I was looking for.
> > Can't explain why I missed that, thanks!
> 
> Ahh, now I can explain ;-)
> It's the port's version (v0.9_1,1) which lacks this feature.
> I saw on github that you added this functionality in February 2014, but
> VERSION wasn't bumped since June 2013.
> So I guess the port does checkout an outdated version?
> 
> Thanks,
> 
> -Harry
> 

That is it, but I lack motivation to work on it. If one want to take
maintainership on it and update it, please help yourself

Bapt


pgpzz7NIVJTGr.pgp
Description: PGP signature

Re: missing nullmailer feature in dma(8)/dmagent

[Kurt Jaeger]

Hi!

[ports/mail/dma]

> > >> The NULLCLIENT feature should exactly be what you are looking for, no?
> > >> As written in the manpage:
[...]

> > Ahh, now I can explain ;-)
> > It's the port's version (v0.9_1,1) which lacks this feature.
> > I saw on github that you added this functionality in February 2014, but
> > VERSION wasn't bumped since June 2013.
> > So I guess the port does checkout an outdated version?

> That is it, but I lack motivation to work on it. If one want to take
> maintainership on it and update it, please help yourself

I'll have a look at it, but it does not build with 9.1-amd64 or 8.4-i386
in poudriere (it does build on 10.0).

-- 
p...@opsec.eu+49 171 3101372 6 years to go !
___
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: missing nullmailer feature in dma(8)/dmagent

[Harald Schmalzbauer]

 Bezüglich Baptiste Daroussin's Nachricht vom 03.11.2014 13:20 (localtime):
> On Mon, Nov 03, 2014 at 12:52:04PM +0100, Harald Schmalzbauer wrote:
>>  Bezüglich Harald Schmalzbauer's Nachricht vom 28.10.2014 17:54
>> (localtime):
>>>  Bezüglich Baptiste Daroussin's Nachricht vom 28.10.2014 17:44 (localtime):
>>> …
 The NULLCLIENT feature should exactly be what you are looking for, no?
 As written in the manpage:

 
 Bypass aliases and local delivery, and instead forward all mails to
 the defined `SMARTHOST'.  `NULLCLIENT' requires `SMARTHOST' to be
 set.
 
>>> Doh… should try harder getting more sleep ;-)
>>> Sorry for the noise, seems indeed to be exactly what I was looking for.
>>> Can't explain why I missed that, thanks!
>> Ahh, now I can explain ;-)
>> It's the port's version (v0.9_1,1) which lacks this feature.
>> I saw on github that you added this functionality in February 2014, but
>> VERSION wasn't bumped since June 2013.
>> So I guess the port does checkout an outdated version?
>>
>> Thanks,
>>
>> -Harry
>>
> That is it, but I lack motivation to work on it. If one want to take
> maintainership on it and update it, please help yourself

Fair enough. Unfortunately both, time and skills are limited; sufficient
to help myself, though.
For anyone intersted, attached is a diff which does a quick'n'dirty
dma-devel (copy mail/dma to inofficial/dma-devel and apply the patch).
Packaging works, can't tell anything about the condition of the GitHub
code from Sep, 8th 2014 (commit
b1056e4384472dbbedd6b075819abd6154ac0d69) but I don't expect regressions
so will use it and would report if I found problems.

Thanks,

-Harry
diff -ur mail/dma/Makefile inofficial/dma-devel/Makefile
--- mail/dma/Makefile	2014-11-03 14:24:47.430297295 +0100
+++ inofficial/dma-devel/Makefile	2014-11-03 15:12:43.791680603 +0100
@@ -1,22 +1,26 @@
 # Created by: Daniel Roethlisberger 
 # $FreeBSD: head/mail/dma/Makefile 367307 2014-09-04 19:26:24Z antoine $
 
-PORTNAME=	dma
-PORTVERSION=	v0.9
-PORTREVISION=	1
-PORTEPOCH=	1
+PORTNAME=	dma-devel
+PORTVERSION=	v0.10
+#PORTREVISION=	1
+#PORTEPOCH=	1
 CATEGORIES=	mail ipv6
 EXTRACT_SUFX=
+CONFLICTS_INSTALL= dma-*
 
 MAINTAINER=	b...@freebsd.org
 COMMENT=	DragonFly Mail Agent, a small MTA for local/outbound mail
 
+VALID_CATEGORIES+=	inofficial
+
 LICENSE=	BSD3CLAUSE
 
 USE_OPENSSL=	yes
 
 USE_GITHUB=	yes
-GH_COMMIT=	2bb8bcb
+GH_PROJECT=	dma
+GH_COMMIT=	b1056e4
 GH_ACCOUNT=	corecode
 GH_TAGNAME=	${GH_COMMIT}
 
diff -ur mail/dma/distinfo inofficial/dma-devel/distinfo
--- mail/dma/distinfo	2014-11-03 14:24:47.450316423 +0100
+++ inofficial/dma-devel/distinfo	2014-11-03 14:59:00.438986799 +0100
@@ -1,2 +1,2 @@
-SHA256 (dma-v0.9) = 6c99d5975a2a1072f74b3209ad0a2b89558274de39bd3e03400f94a242b436f2
-SIZE (dma-v0.9) = 45611
+SHA256 (dma-devel-v0.10) = 05348aa91e838d819627a31db82afbdb4edba5fa4a81e90992616e031761eea2
+SIZE (dma-devel-v0.10) = 33985


signature.asc
Description: OpenPGP digital signature

Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so

[O. Hartmann]

On Thu, 30 Oct 2014 16:47:02 -0400 (EDT)
Benjamin Kaduk  wrote:

> [stripping -questions; please don't cross-post]
> 
> Disclaimer: I am part of the group that develops MIT Kerberos
> 
> On Thu, 30 Oct 2014, O. Hartmann wrote:
> 
> > Searching for suitable manuals, I found some HowTos describing how
> > to setup MIT Kerberos V with an OpenLDAP backend and I started
> > following the instructions there. Despite the fact that
> > http://www.h5l.org/manual
> 
> I am not sure why.  I guess you already discovered this, but the MIT
> KDC and the Heimdal KDC are very different beasts to administer.  The
> instructions for one have no bearing on the other.

Indeed, I did, but I was under the impression both suites share
mutuality. Its long time ago since I had contact to KRB5.

> 
> > is dead(!) and no usefull documentation or any kind of a hint where
> > to
> 
> That was reported to their mailing list independently just today
> (http://permalink.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/7836)

I also sent notices to heim...@h5l.org (hoping someone is listening at
the backend there). A of today, the site is still unresponsive
regarding documentation. The links are dead, 404 ERROR.

> 
> > find useful documentation for Heimdal can be found, many of the MIT
> > Kerberos V setup instructions seem to be a dead end when using
> > Heimdal on FreeBSD. Most of the links on that heimdal site ends up
> > in ERROR 404!
> >
> > Well, I think my objective isn't that exotic in an more advanced
> > server environment and I think since FreeBSD is supposed to be used
> > in advanced server environments this task should be well known - but
> > little information/documentation is available.
> 
> In my experience, most people getting into administering Kerberos
> KDCs do so by learning from someone else already doing so (usually in
> the same organization), so there are not always written
> documentation.  In my (biased) opinion, the MIT documentation is
> pretty good; the upstream Heimdal documentation less so.

Well, to make it short and not to start a flame war, I disagree. In
my/our case, I'm the root or will become such a root to be asked. In
such a case good software is also measured by its documentation for
exactly that purpose (apart from reading/understanding the source code,
if available).

> 
> > Nevertheless, I use the base system's heimdal implementation and I
> > run into a very frustrating error when trying to run "kamdin -l":
> >
> > kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so:
> > Cannot open "/usr/lib/hdb_ldap.so"
> >
> > The setup for the stanza [kdc] is
> >
> > [...]
> > [kdc]
> > database ={
> > dbname=ldap:ou=kerberos,dc=server,dc=gdr
> > #hdb-ldap-structural-object = inetOrgPerson
> > mkey_file = /var/heimdal/m-key
> > acl_file = /var/heimdal/kadmind.acl
> > }
> >
> > instructions taken from  http://www.padl.com/Research/Heimdal.html.
> >
> > Well, it seems that FreeBSD ships with a crippled heimdal
> > implementation. Where is /usr/lib/hdb_ldap.so?
> 
> You keep using this word "crippled", and I fail to understand why.
> It is functioning as intended.  The FreeBSD base system ships with a
> limited set of tools, which allow many common server tasks to be
> performed, but certainly not all, and are not intended to fulfil all
> advanced server setups.  The bundled Heimdal is there to provide the
> libraries and client utilities, which can be indispensable in many
> environments, and the KDC implementation is included because it can
> be useful in simple, small setups.  If you need a more complicated
> Kerberos setup, you should be installing a KDC from ports, or
> arguably even building from source!  The KDC in base functions
> suitably for the role it is intended to play; that is hardly
> "crippled".

Yes, I was in that case a bit fast with my statement (which I still
hold with respect to a "roundish and complete system") but when I
thought about how FreeBSD would implement kerberized services, I was
remembered that at least the basic libraries need to be present.

I regret that important pieces like Kerberos/Heimdal (specially the
last) and OpenLDAP are not part of the base system but in this case, we
tend to have a philosophical dicussion and end up in the way the Linux
distributions are handled. I have an insight in the unfortune logic of
mine, my apologizes.

> 
> You probably noted that the base system now has dma, and sendmail is
> on its way out.  Sendmail is a pretty big hammer, bigger than what is
> needed for use by the base system, and dma is more appropriate.  The
> tools in the base system have a purpose, and they are not always
> suitable for everything in their appropriate area.
> 
> > I'm toying around this issue for several days now and it gets more
> > and more frustrating, also with the perspective of having no
> > running samba 4.1 server for the windows domain.
> >
> > Can someone giv

systat -ifstat on high-speed links

[Slawa Olhovchenkov]

I am try to use 'systat -ifstat 1' when traffic over network intrface
about 35Gbit. systat show about 2.5Gbit.
Where is 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: systat -ifstat on high-speed links

[Ryan Stone]

http://svnweb.freebsd.org/changeset/base/272284
___
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: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so

[Benjamin Kaduk]

On Mon, 3 Nov 2014, O. Hartmann wrote:

> On Thu, 30 Oct 2014 16:47:02 -0400 (EDT)
> Benjamin Kaduk  wrote:
>
> > On Thu, 30 Oct 2014, O. Hartmann wrote:
> >
> Indeed, I did, but I was under the impression both suites share
> mutuality. Its long time ago since I had contact to KRB5.

The kerberos v5 protocol is an IETF standard, and a heimdal krb5 client
will interoperate with an MIT (or even Microsoft!) server, and vice versa.
The same cannot be said of the kadmin protocols or the database
administration tools, as those are not part of the core kerberos v5
protocol.

> I also sent notices to heim...@h5l.org (hoping someone is listening at

I'm actually unsure whether that list is active.  I think I'm only on
heimdal-discuss.

> > In my experience, most people getting into administering Kerberos
> > KDCs do so by learning from someone else already doing so (usually in
> > the same organization), so there are not always written
> > documentation.  In my (biased) opinion, the MIT documentation is
> > pretty good; the upstream Heimdal documentation less so.
>
> Well, to make it short and not to start a flame war, I disagree. In
> my/our case, I'm the root or will become such a root to be asked. In
> such a case good software is also measured by its documentation for
> exactly that purpose (apart from reading/understanding the source code,
> if available).

Between us, we still don't have enough data to say anything for sure, so
I'll drop it.

> > (Are you even tied to Heimdal?  If not, you already found the
> > documentation for using LDAP as a backend for an MIT KDC...)
>
> Well, the use of Heimdal has political issues - for the now and
> the future. Following your recommenadations and lookig for the
> documentation of MIT Kerberos, I realized that indeed the docs are
> much more complete - even from the simplest point of view, namelythe
> accesibility of the server(s) providing the documentation. But as I
> said, the decission is a more political one.

Okay.  I can't argue with that.

> >
> > From your later message:
> >
> > > The lack of documentation is simply a mess. I excluded by intention
> > > the port security/heimdal to proof whether FreeBSD is capable of
> > > handling a common and very usual  server task like the mentioned
> > > scenario.
> >
> > I cannot agree that your mentioned scenario is common and very
> > usual.  In my experience the majority of Unix standalone KDC
> > deployments use the default (local) database backend, not an LDAP
> > backend.  (Fancy things like Samba, IPA, and AD are different, but
> > they are also not in the domain of things in the base system!)
>
> Well, FreBSD is supposed to handle larger environments and not
> home-office or toy systems - that is what is always inside the messages
> I get and that what I read "inbetween" the written rows. Logically, I
> conclude that many others utilizing FBSD as a server backend for their
> purposes even in larger or even big environments use RADIUS or LDAP as
> backend in combination with Kerberos/Heimdal.
>
> From what experiences I exchanged with other administrators at the
> departments, the use of OpenLDAP as a backend for kerberos/Heimdal
> isn't that unusual due to the sophisticated replication mechanism,
> which convinced my. I also have some specific schematics were OpenLDAP
> as the backend would come in handy (presuming a etup which respects
> several security issues).

Sure, an LDAP backend has nice features (it might be slower, though).  I
don't think an attempt to bring an OpenLDAP server into the FreeBSD base
system would succeed, though, so heimdal from ports is the only option in
this case.

> > I don't know if you followed the MIT documentation this far, but an
> > MIT KDC needing to authenticate to bind to its LDAP server needs to
> > have configuration for this in kdc.conf.
>
> Well, the last point is making me floating dead in the water - I can
> find some informations for MIT Kerberos V, but I can not find those for
> heimdal and with the Heimdal documentation server down and not mirrored
> the situation is unresovable right now.
>
> I can not even evaluate whether the concept I'm thinking of is possible
> or now (lack of docs!). The OpenLDAP daemon requires TLS-secured access
> with a certain "security strength factor" for all inbound access. Such
> a security concept is defined in the toplevel cn=config structure.  My
> thinking was to have an exception defined by olcAccess rulesets
> nullifying the SSF for the localhost or the unix-domainsocket, but
> olcAccess isn't allowed at that level - so the KDC needs to contact
> its LDAP backend via TLS secured connectsion - and I do not know
> whether this is possible in Heimdal - and how to configure this request
> properly. If it is impossible, I probably have to go with a
> client-based access via SSL certificate which drives the complexity of
> the setup for the whole domain into problematic regions. Then your
> suggestion of falling back to a dedicated LDAP 

Re: systat -ifstat on high-speed links

[Slawa Olhovchenkov]

On Mon, Nov 03, 2014 at 11:58:56AM -0500, Ryan Stone wrote:

> http://svnweb.freebsd.org/changeset/base/272284

Date:   Mon Sep 29 17:38:50 2014 UTC (4 weeks, 6 days ago)
MFC after:  1 week

MFC stoped?
___
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: ssh None cipher

[Freddie Cash]

On Sat, Oct 18, 2014 at 12:32 PM, Allan Jude  wrote:

> On 2014-10-18 13:21, Freddie Cash wrote:
> > On Oct 18, 2014 3:54 AM, "Mark Martinec" 
> > wrote:
> >>
> >> If the purpose of having a none cipher is to have a fast
> >> file transfer, then one should be using  sysutils/bbcp
> >> for that purposes. Uses ssd for authentication, and
> >> opens unencrypted channel(s) for the actual data transfer.
> >> It's also very fast, can use multiple TCP streams.
> >
> > That's an interesting alternative to rsync, scp, and ftp, but doesn't
> help
> > with zfs send/recv which is where the none cipher really shines.
> >
> > Without the none cipher, SSH becomes the bottleneck limiting transfers to
> > around 400 Mbps on a gigabit LAN. With the none cipher, the network
> becomes
> > the bottleneck limiting transfers to around 920 Mbps on the same gigabit
> > LAN.
> >
> > This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs.
>
> Actually, looking into it, the bbcp command can support a pipe at each
> end instead of files, so you can actually do a zfs send | zfs receive
> via bbcp, and use multiple concurrent connections, to get around TCP
> window stuff when going transatlantic
>
> I am going to be trying it out shortly.
>
> Note: the other big improvement in newer ssh is the HPN stuff, that is
> switched on since 9.2 I think.


​After much finagling and testing, I have managed to incorporate bbcp into
my ZFS send/recv script.  And it works much better than regular, encrypted
SSH in my setup.

Regular SSH transfers tended to top out around 400 Mbps, using 100% of 1
CPU.  Was not able to get the multi-threadded AES cipher working.

SSH connections using the NONE cipher saturated the gigabit link with
minimal CPU usage.

And a bbcp connection is currently running between 500-800 Mbps (depending
on the size of the snpashot), also with minimal CPU usage.

NOTE:  I expect this be running much better next week, as the receiving
pool is currently resilvering a drive, slowing everything down.


Got things working using the following bbcp command format:

bbcp -N io "zfs send -I pool/fs@snap1 pool/fs@snap2" username@remotesys:"zfs
recv -d pool"


Have not played with any of the myriad tuning options for bbcp.  Just
wanted to see if I could get it to work, and how an untuned connection
compared to an untuned SSH connection (with and without NONE cipher).  So
far, I'm impressed.

​Thanks for the suggestion.  It's another tool in the box.  :)​

-- 
Freddie Cash
fjwc...@gmail.com
___
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"

Asmc not working in EFI

[Anders Bolt-Evensen]

Hello!
Whenever I try to load the asmc kernel module on my Mac in EFI mode (it's a 
MacBookPro8,3, which I've added to asmc.c), I'm getting an error message that 
says "asmc0: model not recognized.

However, when I install FreeBSD to a hard drive using MBR, then add 
MacBookPro8,3 to asmc.c, compile the kernel and then load the module, 
everything works as it should. But, when I do the same on a disk using EFI on 
the same Mac, this "model not recognized" message appears.

Does any of you know why asmc does not work in EFI?

Anders
Sent from my iPhone
___
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"

CTF: geom gate network patch

[John-Mark Gurney]

John-Mark Gurney wrote this message on Fri, Oct 17, 2014 at 09:58 -0700:
> Sourish Mazumder wrote this message on Fri, Oct 17, 2014 at 17:34 +0530:
> > I am planning to use geom gate network for accessing remote disks. I set up
> > geom gate as per the freebsd handbook. I am using freebsd 9.2.
> > I am noticing heavy performance impact for disk IO when using geom gate. I
> > am using the dd command to directly write to the SSD for testing
> > performance. The IOPS gets cut down to 1/3 when accessing the SSD remotely
> > over a geom gate network, compared to the IOPS achieved when writing to the
> > SSD directly on the system where the SSD is attached.
> > I thought that there might be some problems with the network, so decided to
> > create a geom gate disk on the same system where the SSD is attached. This
> > way the IO is not going over the network. However, in this use case I
> > noticed the IOPS get cut down to 2/3 compared to IOPS achieved when writing
> > to the SSD directly.
> > 
> > So, I have a SSD and its geom gate network disk created on the same node
> > and the same IOPS test using the dd command gives 2/3 IOPS performance for
> > the geom gate disk compared to running the IOPS test directly on the SSD.
> > 
> > This points to some performance issues with the geom gate itself.
> 
> Not necessarily...  Yes, it's slower, but at the same time, you now have
> to run lots of network and TCP code in addition to the IO for each and
> every IO...
> 
> > Is anyone aware of any such performance issues when using geom gate network
> > disks? If so, what is the reason for such IO performance drop and are there
> > any solutions or tuning parameters to rectify the performance drop?
> > 
> > Any information regarding the same will be highly appreciated.
> 
> I did some work at this a while back... and if you're interested in
> improving performance and willing to do some testing... I can send you
> some patches..
> 
> There are a couple issues that I know about..
> 
> First, ggate specificly sets the buffer sizes, which disables the
> autosizing of TCP's window.. This means that if you have a high latency,
> high bandwidth link, you'll be limited to 128k / rtt of bandwidth.
> 
> Second is that ggate isn't issueing multiple IOs at a time.  This means
> that any NCQ or tagging isn't able to be used, where as when running
> natively they can be used...

I've attached a patch I would like other ggate users to test and
verify that there aren't bugs, or performance regressions by using
this patch.

The patch is also available at:
https://www.funkthat.com/~jmg/patches/ggate.patch

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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"

Asmc not working in EFI

[Anders Bolt-Evensen]

Hello!
Whenever I try to load the asmc kernel module on my Mac in EFI mode (it's a 
MacBookPro8,3, which I've added to asmc.c), I'm getting an error message that 
says "asmc0: model not recognized.

However, when I install FreeBSD to a hard drive using MBR, then add 
MacBookPro8,3 to asmc.c, compile the kernel and then load the module, 
everything works as it should. But, when I do the same on a disk using EFI on 
the same Mac, this "model not recognized" message appears.

Does any of you know why asmc does not work in EFI?

Anders
Sent from my iPhone
___
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: ssh None cipher

[Vsevolod Stakhov]

On 03/11/14 17:59, Freddie Cash wrote:

On Sat, Oct 18, 2014 at 12:32 PM, Allan Jude  wrote:


On 2014-10-18 13:21, Freddie Cash wrote:

On Oct 18, 2014 3:54 AM, "Mark Martinec" 
wrote:


If the purpose of having a none cipher is to have a fast
file transfer, then one should be using  sysutils/bbcp
for that purposes. Uses ssd for authentication, and
opens unencrypted channel(s) for the actual data transfer.
It's also very fast, can use multiple TCP streams.


That's an interesting alternative to rsync, scp, and ftp, but doesn't

help

with zfs send/recv which is where the none cipher really shines.

Without the none cipher, SSH becomes the bottleneck limiting transfers to
around 400 Mbps on a gigabit LAN. With the none cipher, the network

becomes

the bottleneck limiting transfers to around 920 Mbps on the same gigabit
LAN.

This is between two 8-core AMD Opteron 6200 systems using igb(4) NICs.


Actually, looking into it, the bbcp command can support a pipe at each
end instead of files, so you can actually do a zfs send | zfs receive
via bbcp, and use multiple concurrent connections, to get around TCP
window stuff when going transatlantic

I am going to be trying it out shortly.

Note: the other big improvement in newer ssh is the HPN stuff, that is
switched on since 9.2 I think.



​After much finagling and testing, I have managed to incorporate bbcp into
my ZFS send/recv script.  And it works much better than regular, encrypted
SSH in my setup.

Regular SSH transfers tended to top out around 400 Mbps, using 100% of 1
CPU.  Was not able to get the multi-threadded AES cipher working.

SSH connections using the NONE cipher saturated the gigabit link with
minimal CPU usage.

And a bbcp connection is currently running between 500-800 Mbps (depending
on the size of the snpashot), also with minimal CPU usage.

NOTE:  I expect this be running much better next week, as the receiving
pool is currently resilvering a drive, slowing everything down.


Got things working using the following bbcp command format:

bbcp -N io "zfs send -I pool/fs@snap1 pool/fs@snap2" username@remotesys:"zfs
recv -d pool"


Have not played with any of the myriad tuning options for bbcp.  Just
wanted to see if I could get it to work, and how an untuned connection
compared to an untuned SSH connection (with and without NONE cipher).  So
far, I'm impressed.

​Thanks for the suggestion.  It's another tool in the box.  :)​



I have also written an utility[1] to efficiently encrypt and 
authenticate data transferred over the network using the modern AES-GCM 
or chacha20-poly1305 ciphers with pre-shared keys (or passwords). It can 
use multiple cores at a time allowing up to 32 gigabits per second.


[1] - https://github.com/vstakhov/hpenc
___
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: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so

[O. Hartmann]

Am Mon, 3 Nov 2014 12:12:03 -0500 (EST)
Benjamin Kaduk  schrieb:

> On Mon, 3 Nov 2014, O. Hartmann wrote:
> 
> > On Thu, 30 Oct 2014 16:47:02 -0400 (EDT)
> > Benjamin Kaduk  wrote:
> >
> > > On Thu, 30 Oct 2014, O. Hartmann wrote:
> > >
> > Indeed, I did, but I was under the impression both suites share
> > mutuality. Its long time ago since I had contact to KRB5.
> 
> The kerberos v5 protocol is an IETF standard, and a heimdal krb5 client
> will interoperate with an MIT (or even Microsoft!) server, and vice versa.
> The same cannot be said of the kadmin protocols or the database
> administration tools, as those are not part of the core kerberos v5
> protocol.
> 
> > I also sent notices to heim...@h5l.org (hoping someone is listening at
> 
> I'm actually unsure whether that list is active.  I think I'm only on
> heimdal-discuss.
> 
> > > In my experience, most people getting into administering Kerberos
> > > KDCs do so by learning from someone else already doing so (usually in
> > > the same organization), so there are not always written
> > > documentation.  In my (biased) opinion, the MIT documentation is
> > > pretty good; the upstream Heimdal documentation less so.
> >
> > Well, to make it short and not to start a flame war, I disagree. In
> > my/our case, I'm the root or will become such a root to be asked. In
> > such a case good software is also measured by its documentation for
> > exactly that purpose (apart from reading/understanding the source code,
> > if available).
> 
> Between us, we still don't have enough data to say anything for sure, so
> I'll drop it.
> 
> > > (Are you even tied to Heimdal?  If not, you already found the
> > > documentation for using LDAP as a backend for an MIT KDC...)
> >
> > Well, the use of Heimdal has political issues - for the now and
> > the future. Following your recommenadations and lookig for the
> > documentation of MIT Kerberos, I realized that indeed the docs are
> > much more complete - even from the simplest point of view, namelythe
> > accesibility of the server(s) providing the documentation. But as I
> > said, the decission is a more political one.
> 
> Okay.  I can't argue with that.
> 
> > >
> > > From your later message:
> > >
> > > > The lack of documentation is simply a mess. I excluded by intention
> > > > the port security/heimdal to proof whether FreeBSD is capable of
> > > > handling a common and very usual  server task like the mentioned
> > > > scenario.
> > >
> > > I cannot agree that your mentioned scenario is common and very
> > > usual.  In my experience the majority of Unix standalone KDC
> > > deployments use the default (local) database backend, not an LDAP
> > > backend.  (Fancy things like Samba, IPA, and AD are different, but
> > > they are also not in the domain of things in the base system!)
> >
> > Well, FreBSD is supposed to handle larger environments and not
> > home-office or toy systems - that is what is always inside the messages
> > I get and that what I read "inbetween" the written rows. Logically, I
> > conclude that many others utilizing FBSD as a server backend for their
> > purposes even in larger or even big environments use RADIUS or LDAP as
> > backend in combination with Kerberos/Heimdal.
> >
> > From what experiences I exchanged with other administrators at the
> > departments, the use of OpenLDAP as a backend for kerberos/Heimdal
> > isn't that unusual due to the sophisticated replication mechanism,
> > which convinced my. I also have some specific schematics were OpenLDAP
> > as the backend would come in handy (presuming a etup which respects
> > several security issues).
> 
> Sure, an LDAP backend has nice features (it might be slower, though).  I
> don't think an attempt to bring an OpenLDAP server into the FreeBSD base
> system would succeed, though, so heimdal from ports is the only option in
> this case.
> 
> > > I don't know if you followed the MIT documentation this far, but an
> > > MIT KDC needing to authenticate to bind to its LDAP server needs to
> > > have configuration for this in kdc.conf.
> >
> > Well, the last point is making me floating dead in the water - I can
> > find some informations for MIT Kerberos V, but I can not find those for
> > heimdal and with the Heimdal documentation server down and not mirrored
> > the situation is unresovable right now.
> >
> > I can not even evaluate whether the concept I'm thinking of is possible
> > or now (lack of docs!). The OpenLDAP daemon requires TLS-secured access
> > with a certain "security strength factor" for all inbound access. Such
> > a security concept is defined in the toplevel cn=config structure.  My
> > thinking was to have an exception defined by olcAccess rulesets
> > nullifying the SSF for the localhost or the unix-domainsocket, but
> > olcAccess isn't allowed at that level - so the KDC needs to contact
> > its LDAP backend via TLS secured connectsion - and I do not know
> > whether this is possible in Heimdal - and how to configure th

Re: CURRENT: EFI boot failure

[O. Hartmann]

Am Tue, 23 Sep 2014 17:14:46 +0200
Dimitry Andric  schrieb:

> On 23 Sep 2014, at 17:00, Nathan Whitehorn  wrote:
> > On 09/23/14 07:28, Harald Schmalzbauer wrote:
> >>  Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
> >>> …
> >>> The problem I reported about in the first place is triggered by a faulty 
> >>> loader.efi
> >>> that arises, when optimisation level is -O3. -O2 works fine.
> >> I can confirm that this problem also shows up when using
> >> 'CPUTYPE?=core-avx2'
> >> Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
> >> 
> >> I could narrow down the cause to libefi.a (sys/boot/efi).
> >> But I don't understand the things going on there, so no clue how to fix
> >> besides maybe
> >> 
> >> --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
> >> +++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
> >> @@ -2,6 +2,10 @@
> >> 
> >> BINDIR?= /boot
> >> 
> >> +.ifdef CPUTYPE
> >> +.undef CPUTYPE
> >> +.endif
> >> +
> >> .if ${MACHINE_CPUARCH} == "i386"
> >> CFLAGS+= -march=i386
> >> .endif
> > Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9?
> > -Nathan
> 
> IMHO CPUTYPE should be ignored for any boot loader program, and the
> lowest common denominator should be used instead (i486 for 32-bit, plain
> x86_64 for 64-bit).  It makes no sense to optimize boot loaders for e.g.
> core-avx2. :-)
> 
> But indeed, it appears that we need to add more -mno-foo magic flags...
> 
> -Dimitry
> 

I repoted a bug at
Bug 194641 - [EFI] boot/loader.efi: miscompilation on Intel Haswell with AVX2 


Please feel free to comment and replenish my superficial observation.

Hopefullz, this doesn't get lost. This nasty bug on Haswell CPU bothers me all 
the days I
update world.


pgpXizPiSBZKe.pgp
Description: OpenPGP digital signature

Re: pkg 1.4 freeze please test test test!

[Hans Petter Selasky]

Hi,

Is it possible when upgrading a system via "pkg" to selectivly switch 
upgrades ON/OFF. For example I have a custom ffmpeg install and would 
like to keep it every time I do a binary upgrade?


--HPS
___
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: pkg 1.4 freeze please test test test!

[Freddie Cash]

On Mon, Nov 3, 2014 at 1:40 PM, Hans Petter Selasky  wrote:

> Is it possible when upgrading a system via "pkg" to selectivly switch
> upgrades ON/OFF. For example I have a custom ffmpeg install and would like
> to keep it every time I do a binary upgrade?
>


​# man pkg-lock

;)

I believe that's what you are looking for.​  No idea how well it works
long-term, though, or if you lock a large number of packages.


-- 
Freddie Cash
fjwc...@gmail.com
___
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: pkg 1.4 freeze please test test test!

[Henry Hu]

On Mon, Nov 3, 2014 at 4:48 PM, Freddie Cash  wrote:

> On Mon, Nov 3, 2014 at 1:40 PM, Hans Petter Selasky 
> wrote:
>
> > Is it possible when upgrading a system via "pkg" to selectivly switch
> > upgrades ON/OFF. For example I have a custom ffmpeg install and would
> like
> > to keep it every time I do a binary upgrade?
> >
>
>
> ​# man pkg-lock
>
> ;)
>
> I believe that's what you are looking for.​  No idea how well it works
> long-term, though, or if you lock a large number of packages.
>

I also use pkg-lock, but it has several problems:
* You may miss updates. They are skipped during pkg upgrade
* "xxx is locked and may not be modified" is displayed every time you do
something like pkg upgrade. If you have multiple pkgs locked, it may be
annoying.

It would be easier to update the pkgs by having something like portmaster
-P.

>
>
> --
> Freddie Cash
> fjwc...@gmail.com
> ___
> 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"




-- 
Cheers,
Henry
___
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"

Build failed in Jenkins: FreeBSD_HEAD #1766

[jenkins-admin]

See 

Changes:

[ngie] Commit missing header for sys/time.h compat on NetBSD to unbreak the 
amd64/i386
build

Pointyhat to: me (forgot to svn add it sooner)

[ngie] As an optimization (in simple, well used cases) only call cat ${.ALLSRC} 
when
generating files from various sources instead of calling cat ${.ALLSRC} | sed

The perl case was skipped because it's not being used in the tree at this time

[tychon] Improve the ability to cancel an in-flight request by using an
interrupt, via SIGCONT, to force the read or write system call to
return prematurely.

Reviewed by:grehan

[ngie] Add reachover Makefiles for contrib/netbsd-tests/lib/libc; this adds 
approximately
500 new testcases

Various TODOs have been sprinkled around the Makefiles for items that even need
to be ported (missing features), testcases have issues with building/linking, or
issues at runtime.

A variant of this code has been tested extensively on amd64 and i386
10-STABLE/11-CURRENT for several months without issue. It builds on other
architectures, but the code will remain off until I have prove it works on
virtual hardware or real hardware on other architectures

In collaboration with: pho, Casey Peel 
Sponsored by: EMC / Isilon Storage Division

--
[...truncated 107148 lines...]
--- .depend.h_spawnattr ---
rm -f .depend.h_spawnattr
CC='cc  ' mkdep -f .depend.h_spawnattr -a -std=gnu99   

--- libexec.depend__D ---
echo bootptest: 
/usr/obj
  >> .depend
--- bin.depend__D ---
--- depend_subdir_date ---
===> bin/date (depend)
--- lib.depend__D ---
echo h_spawnattr: 
/usr/obj
  >> .depend.h_spawnattr
(cd 

 && make -f 

 _RECURSING_PROGS=  SUBDIR= PROG=fileactions_test  
DEPENDFILE=.depend.fileactions_test .MAKE.DEPENDFILE=.depend.fileactions_test   
depend)
--- bin.depend__D ---
--- _sub.depend ---
===> bin/date/tests (depend)
--- lib.depend__D ---
--- .depend.fileactions_test ---
rm -f .depend.fileactions_test
CC='cc  ' mkdep -f .depend.fileactions_test -a
-I 
-I 
-I
 -std=gnu99   

--- bin.depend__D ---
--- scripts.depend ---
(cd  && 
make -f 

 SUBDIR= _RECURSING_PROGS=  depend)
--- lib.depend__D ---
echo fileactions_test: 
/usr/obj
  
/usr/obj
 >> .depend.fileactions_test
--- bin.depend__D ---
--- .depend ---
rm -f .depend
--- lib.depend__D ---
(cd 

 && make -f 

 _RECURSING_PROGS=  SUBDIR= PROG=spawn_test  DEPENDFILE=.depend.spawn_test 
.MAKE.DEPENDFILE=.depend.spawn_test   depend)
--- bin.depend__D ---
CC='cc  ' mkdep -f .depend -a -std=gnu99   
 
 

--- libexec.depend__D ---
--- .depend ---
echo bootpd: 
/usr/obj
  >> .depend
===> libexec/casper (depend)
--- lib.depend__D ---
--- .depend.spawn_test ---
rm -f .depend.spawn_test
CC='cc  ' mkdep -f .depend.spawn_test -a
-I 
-I 
-I
 -std=gnu99   

--- libexec.depend__D ---
--- _sub.depend ---
===> libexec/casper/dns (depend)
--- .depend ---
rm -f .depend
CC='cc  ' mkdep -f .depend -a
-I 
-I

Re: Build failed in Jenkins: FreeBSD_HEAD #1766

[Garrett Cooper]

On Nov 3, 2014, at 20:16, jenkins-ad...@freebsd.org wrote:

> See 
> 
> Changes:
> 
> [ngie] Commit missing header for sys/time.h compat on NetBSD to unbreak the 
> amd64/i386
> build
> 
> Pointyhat to: me (forgot to svn add it sooner)
> 
> [ngie] As an optimization (in simple, well used cases) only call cat 
> ${.ALLSRC} when
> generating files from various sources instead of calling cat ${.ALLSRC} | sed
> 
> The perl case was skipped because it's not being used in the tree at this time
> 
> [tychon] Improve the ability to cancel an in-flight request by using an
> interrupt, via SIGCONT, to force the read or write system call to
> return prematurely.
> 
> Reviewed by:  grehan
> 
> [ngie] Add reachover Makefiles for contrib/netbsd-tests/lib/libc; this adds 
> approximately
> 500 new testcases
> 
> Various TODOs have been sprinkled around the Makefiles for items that even 
> need
> to be ported (missing features), testcases have issues with building/linking, 
> or
> issues at runtime.
> 
> A variant of this code has been tested extensively on amd64 and i386
> 10-STABLE/11-CURRENT for several months without issue. It builds on other
> architectures, but the code will remain off until I have prove it works on
> virtual hardware or real hardware on other architectures

This failure is because of the changes I just added and the fact that 
ATF was just upgraded to 0.2.1. I’ll fix this ASAP.
Thank you...


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: pkg 1.4 freeze please test test test!

[Kevin Oberman]

--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.comOn Mon, Nov 3, 2014 at 5:09 PM, Henry Hu <
henry.hu...@gmail.com> wrote:

> On Mon, Nov 3, 2014 at 4:48 PM, Freddie Cash  wrote:
>
> > On Mon, Nov 3, 2014 at 1:40 PM, Hans Petter Selasky 
> > wrote:
> >
> > > Is it possible when upgrading a system via "pkg" to selectivly switch
> > > upgrades ON/OFF. For example I have a custom ffmpeg install and would
> > like
> > > to keep it every time I do a binary upgrade?
> > >
> >
> >
> > ​# man pkg-lock
> >
> > ;)
> >
> > I believe that's what you are looking for.​  No idea how well it works
> > long-term, though, or if you lock a large number of packages.
> >
>
> I also use pkg-lock, but it has several problems:
> * You may miss updates. They are skipped during pkg upgrade
> * "xxx is locked and may not be modified" is displayed every time you do
> something like pkg upgrade. If you have multiple pkgs locked, it may be
> annoying.
>
> It would be easier to update the pkgs by having something like portmaster
> -P.
> --
> Cheers,
> Henry


I simply do periodic(8) weekly runs of "pkg version -vRl\<" to catch any
port that has not been updated due to being locked. On option to only
report locked packages would simplify this and looks to me like it would be
pretty easy to add, but unless you have a lot of locked packages, it's not
a problem.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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: pkg 1.4 freeze please test test test!

[Darren Pilgrim]

On 11/3/2014 9:50 PM, Kevin Oberman wrote:

I simply do periodic(8) weekly runs of "pkg version -vRl\<" to catch any
port that has not been updated due to being locked. On option to only
report locked packages would simplify this and looks to me like it would be
pretty easy to add, but unless you have a lot of locked packages, it's not
a problem.


I just do `pkg info -ka | egrep 'yes$'`.


___
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: pkg 1.4 freeze please test test test!

[Kevin Oberman]

Thanks you! That dies the trick.

R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com

On Mon, Nov 3, 2014 at 10:51 PM, Darren Pilgrim <
list_free...@bluerosetech.com> wrote:

> On 11/3/2014 9:50 PM, Kevin Oberman wrote:
>
>> I simply do periodic(8) weekly runs of "pkg version -vRl\<" to catch any
>> port that has not been updated due to being locked. On option to only
>> report locked packages would simplify this and looks to me like it would
>> be
>> pretty easy to add, but unless you have a lot of locked packages, it's not
>> a problem.
>>
>
> I just do `pkg info -ka | egrep 'yes$'`.
>
>
>
___
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: pkg 1.4 freeze please test test test!

[Kevin Oberman]

On Mon, Nov 3, 2014 at 11:03 PM, Kevin Oberman  wrote:

> Thanks you! That dies the trick.
>

Or, at least does the trick.

>
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkober...@gmail.com
>
> On Mon, Nov 3, 2014 at 10:51 PM, Darren Pilgrim <
> list_free...@bluerosetech.com> wrote:
>
>> On 11/3/2014 9:50 PM, Kevin Oberman wrote:
>>
>>> I simply do periodic(8) weekly runs of "pkg version -vRl\<" to catch any
>>> port that has not been updated due to being locked. On option to only
>>> report locked packages would simplify this and looks to me like it would
>>> be
>>> pretty easy to add, but unless you have a lot of locked packages, it's
>>> not
>>> a problem.
>>>
>>
>> I just do `pkg info -ka | egrep 'yes$'`.
>>
>>
>>
>
___
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"

Jenkins build is back to normal : FreeBSD_HEAD #1767

[jenkins-admin]

See 

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