Re: Cross-architecture package installs

[Tim Kientzle]

>>> I'm working on tools to build ARM system images.
>>> Usually, these tools run on x86, which creates a problem
>>> for packages.
>> 
>>> 1) Pre-install/post-install scripts.
>>> 
>>>   These obviously don't work since the DESTDIR
>>>   is for a different architecture.
> 
>> This is imho the main problem, and one of the long term goal of pkgng is to 
>> remove as much as possible any pre-instal/post-install scripts.

Well, you're very close to having this work:

The easiest approach I've found is to setup a simple
static webserver, use "pkg repo" to build the catalogue,
then:

echo "Installing packages"
PACKAGESITE=http://my.local.server/packages/arm
export PACKAGESITE
pkg -c $DESTDIR update
pkg -c $DESTDIR install -y pkg
pkg -c $DESTDIR upgrade
pkg -c $DESTDIR install -y emacs-nox11

The only piece missing is that the POST-INSTALL
scripts are failing.

For the packages I'm using, it would be enough to provide
symlink support in the +MANIFEST file directly.  For other
packages, something like the "after next boot fixup" that
I outlined earlier would work.

But this is very, very close.  This is a big step forward
for non-x86 FreeBSD.

Kudos to the pkgng team!

Tim



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 7+ days of dogfood

[b.f.]

On 2/13/13, Steve Kargl  wrote:
> On Wed, Feb 13, 2013 at 02:15:08AM +, b.f. wrote:
>> On 2/13/13, Steve Kargl  wrote:
>> > On Wed, Feb 13, 2013 at 12:18:29AM +, b.f. wrote:
>> >> ># cat /etc/make.conf|grep FFLAGS
>> >> >FFLAGS = -O2 -pipe -march=native -mtune=native
>> >>
>> >> Please do _not_ assign flags unconditionally in make.conf.
>> >
>> > FFLAGS is for compiling Fortran.  I'm one of the people who
>> > has spent years working/patching gfortran.  I think I might
>> > have a better understanding of what options to use with
>> > gfortran than most people.
>> >
>>
>> I know you have, but you are giving advice that is liable to be abused
>> by those who are less experienced.  The flags you are adding are not
>> the problem -- it's the way that you are adding them -- specifically,
>> the assignment in the first line of your snippet, if it's applied
>> unconditionally.  You should either be appending all of them, or
>> assigning them conditionally, so that they are sure to be assigned
>> only once, or -- preferably -- using another makefile that can't be
>> re-read multiple times during a build (ports/Mk/bsd.port.mk
>> automatically includes several makefiles that can be used for this
>> purpose, if you are building a port). You have been lucky not to trip
>> over this: every couple of months for the last several years I have
>> had to debug errors reported by users that arise from this problem. It
>> is more common with CFLAGS and CXXFLAGS but it can happen with FFLAGS,
>> too.
>
> Try 'find /usr/ports -name Makefile -maxdepth 3 | xargs grep FFLAGS'
> Then go read about the options chosen by the various port maintainers.
> I specifically set FFLAGS to avoid the questionable options set in
> the ports.  If -malign-double appears in a port, it should probably
> be marked as broken.  If a port uses -fdefault-real-8, it should probably
> be marked as broken.  If a port uses -ffast-math, it may have issues that
> are extremely difficult to debug.

Okay, so you are doing this advisedly for some specific subset of
ports, and have the knowledge to debug problems that may arise --
others don't.  Undoubtedly some of these additions are suboptimal or
unnecessary -- and I'm sure we'd welcome patches or suggestions to
improve them --  but there are also important additions like the rpath
flags in $PORTSDIR/Mk/bsd.gcc.mk or mangling and PIC directives.  And
not all of the additions are in the ports tree makefiles or
patchfiles: many software distribution makefiles also make additions
that can be clobbered by abusing make.conf.

b.
___
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: 7+ days of dogfood

[Steve Kargl]

On Wed, Feb 13, 2013 at 02:15:08AM +, b.f. wrote:
> On 2/13/13, Steve Kargl  wrote:
> > On Wed, Feb 13, 2013 at 12:18:29AM +, b.f. wrote:
> >> ># cat /etc/make.conf|grep FFLAGS
> >> >FFLAGS = -O2 -pipe -march=native -mtune=native
> >>
> >> Please do _not_ assign flags unconditionally in make.conf.
> >
> > FFLAGS is for compiling Fortran.  I'm one of the people who
> > has spent years working/patching gfortran.  I think I might
> > have a better understanding of what options to use with
> > gfortran than most people.
> >
> 
> I know you have, but you are giving advice that is liable to be abused
> by those who are less experienced.  The flags you are adding are not
> the problem -- it's the way that you are adding them -- specifically,
> the assignment in the first line of your snippet, if it's applied
> unconditionally.  You should either be appending all of them, or
> assigning them conditionally, so that they are sure to be assigned
> only once, or -- preferably -- using another makefile that can't be
> re-read multiple times during a build (ports/Mk/bsd.port.mk
> automatically includes several makefiles that can be used for this
> purpose, if you are building a port). You have been lucky not to trip
> over this: every couple of months for the last several years I have
> had to debug errors reported by users that arise from this problem. It
> is more common with CFLAGS and CXXFLAGS but it can happen with FFLAGS,
> too.

Try 'find /usr/ports -name Makefile -maxdepth 3 | xargs grep FFLAGS'
Then go read about the options chosen by the various port maintainers.
I specifically set FFLAGS to avoid the questionable options set in 
the ports.  If -malign-double appears in a port, it should probably
be marked as broken.  If a port uses -fdefault-real-8, it should probably
be marked as broken.  If a port uses -ffast-math, it may have issues that
are extremely difficult to debug. 

-- 
steve
___
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: CLANG and -fstack-protector

[Eitan Adler]

On 12 February 2013 21:22, Dmitry Marakasov  wrote:
> If there's interest in this, I can refresh the patch and submit it.

Yes.  Please do!



-- 
Eitan Adler
___
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: CLANG and -fstack-protector

[Dmitry Marakasov]

* Kimmo Paasiala (kpaas...@gmail.com) wrote:

> Does the -fstack-protector option work on CLANG 3.1 and 3.2?
> 
> There is thread on FreeBSD forums about the stack protector and ports
> and I'm wondering if it's possible to use the -fstack-protector option
> with CLANG.
> 
> http://forums.freebsd.org/showthread.php?t=36927

You might be interested in this patch:

https://github.com/AMDmi3/freebsd-ports-mk/compare/master...stack-protector

afaik, in prior discussion some years ago an issue was mentioned that
some ports don't build with stack-protector, so I suggested to introduce
STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for
MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need
STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by
enabling stack protector are not transient, so we can have an exp-run
to just mark all uncompatible ports and consider all others compatible).

If there's interest in this, I can refresh the patch and submit it.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
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: 7+ days of dogfood

[b.f.]

On 2/13/13, Steve Kargl  wrote:
> On Wed, Feb 13, 2013 at 12:18:29AM +, b.f. wrote:
>> ># cat /etc/make.conf|grep FFLAGS
>> >FFLAGS = -O2 -pipe -march=native -mtune=native
>>
>> Please do _not_ assign flags unconditionally in make.conf.
>
> FFLAGS is for compiling Fortran.  I'm one of the people who
> has spent years working/patching gfortran.  I think I might
> have a better understanding of what options to use with
> gfortran than most people.
>

I know you have, but you are giving advice that is liable to be abused
by those who are less experienced.  The flags you are adding are not
the problem -- it's the way that you are adding them -- specifically,
the assignment in the first line of your snippet, if it's applied
unconditionally.  You should either be appending all of them, or
assigning them conditionally, so that they are sure to be assigned
only once, or -- preferably -- using another makefile that can't be
re-read multiple times during a build (ports/Mk/bsd.port.mk
automatically includes several makefiles that can be used for this
purpose, if you are building a port). You have been lucky not to trip
over this: every couple of months for the last several years I have
had to debug errors reported by users that arise from this problem. It
is more common with CFLAGS and CXXFLAGS but it can happen with FFLAGS,
too.

b.
___
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: 7+ days of dogfood

[Steve Kargl]

On Wed, Feb 13, 2013 at 12:18:29AM +, b.f. wrote:
> ># cat /etc/make.conf|grep FFLAGS
> >FFLAGS = -O2 -pipe -march=native -mtune=native
> 
> Please do _not_ assign flags unconditionally in make.conf.

FFLAGS is for compiling Fortran.  I'm one of the people who
has spent years working/patching gfortran.  I think I might
have a better understanding of what options to use with
gfortran than most people.

Steve
___
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: 7+ days of dogfood

[b.f.]

># cat /etc/make.conf|grep FFLAGS
>FFLAGS = -O2 -pipe -march=native -mtune=native

Please do _not_ assign flags unconditionally in make.conf.  In fact,
try to remove or restrict the scope of everything in this file. (It is
unfortunate that some of the examples for the base system in the
sample make.conf have been inappropriate for use with other software,
and also that the recent port options changes have encouraged people
to once again dump a lot of stuff into this file.) This is a very
special file: it is included nearly every time make(1) is invoked.  In
addition to the usual concerns about speed, efficiency, and build
pollution, if a port or some other software invokes make(1) more than
once -- and many do -- make.conf is often re-read, and assignments can
clobber necessary prior additions or changes to a variable that were
made elsewhere, sometimes breaking software, and not always in an
obvious way.


>I get building lapack:
>
>gfortran47 -O2 -pipe -march=native -mtune=native -funroll-loops 
>-ftree-vectorize -pg -c slatms.f -o slatms.o
>gfortran47: error: unrecognized command line option '-march=native'
>gfortran47: error: unrecognized argument in option '-mtune=native'
>gfortran47: note: valid arguments to '-mtune=' are: itanium2 mckinley

For example, here it looks like you have clobbered some of the rpath
flag additions made in ports/Mk/bsd.gcc.mk.  This may not break
lapack, but similar changes will almost certainly break some other
software.

b.
___
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: 7+ days of dogfood

[Eitan Adler]

On 12 February 2013 18:23, Jakub Lach  wrote:
> This is good moment to bring that around,
>
> https://wiki.freebsd.org/PortsAndClang
>
> "Help we don't want:
> Submitting ports PR without fixes. We're not yet at the point
> where it can help."
>
> Is not exactly encouraging.

At the time this was written we had exp-runs which told us which ports
were broken with clang.  What we needed help with was fixing those
ports, or marking them known-broken.

I imagine this has changed slightly since then.


-- 
Eitan Adler
___
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: 7+ days of dogfood

[Niclas Zeising]

On 02/13/13 00:23, Jakub Lach wrote:
> This is good moment to bring that around, 
> 
> https://wiki.freebsd.org/PortsAndClang
> 
> "Help we don't want:
> Submitting ports PR without fixes. We're not yet at the point 
> where it can help."

That should probably be removed...
Regards!
-- 
Niclas
___
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: 7+ days of dogfood

[Jakub Lach]

This is good moment to bring that around, 

https://wiki.freebsd.org/PortsAndClang

"Help we don't want:
Submitting ports PR without fixes. We're not yet at the point 
where it can help."

Is not exactly encouraging.



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/7-days-of-dogfood-tp5785452p5786468.html
Sent from the freebsd-current mailing list archive at Nabble.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: 7+ days of dogfood

[Eitan Adler]

On 12 February 2013 17:55, Niclas Zeising  wrote:
> On 02/10/13 07:33, Ian FREISLICH wrote:
>> 1. WITHOUT_CLANG_IS_CC=yes
>>I don't think clang is ready for prime time in FreeBSD, or FreeBSD
>>isn't ready to use clang in prime time.  I got a new laptop (ASUS
>>UX31A) and found that a lot of the ports I needed to install
>>didn't compile or core dumped.  (Sorry I didn't report these to
>>the project).
>>This option sorted that problem out.  However you will need to
>>rebuild everything including world and kernel with gcc before
>>you start building ports with gcc or you will still have problems.
>
> Please please please report ports that fail with clang to ports@ or the
> ports maintainer or both.  If this is not done, then the problems will
> never get fixed (regardless whether it is bad/broken code in the port or
> a bug in clang).

Actually, please file a PR: don't email people privately.

The point remains:  If this is not done, then the problems will never get fixed

-- 
Eitan Adler
___
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: 7+ days of dogfood

[Niclas Zeising]

On 02/10/13 07:33, Ian FREISLICH wrote:
> 1. WITHOUT_CLANG_IS_CC=yes
>I don't think clang is ready for prime time in FreeBSD, or FreeBSD
>isn't ready to use clang in prime time.  I got a new laptop (ASUS
>UX31A) and found that a lot of the ports I needed to install
>didn't compile or core dumped.  (Sorry I didn't report these to
>the project).
>This option sorted that problem out.  However you will need to
>rebuild everything including world and kernel with gcc before
>you start building ports with gcc or you will still have problems.

Please please please report ports that fail with clang to ports@ or the
ports maintainer or both.  If this is not done, then the problems will
never get fixed (regardless whether it is bad/broken code in the port or
a bug in clang).
Regards!
-- 
Niclas
___
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: 7+ days of dogfood

[Niclas Zeising]

On 02/10/13 01:07, Steve Kargl wrote:
> In a long thread started by Peter Wemm on developers@, he described
> the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10.  A
> part of his description included the need to test top-of-tree under
> actual real-world conditions.  In his words, FreeBSD should "eat its
> own dogfood."  The new installation on FreeBSD.org, of course, would
> test FreeBSD-10 under (heavy) server load. 

Just another data point, I haven't read the whole discussion yet.
On my 5 year old laptop (Intel Core2Duo) amd64 system everything works
fine, including intel graphics using WITH_NEW_XORG=, everything built
with clang.  There is no sound issues or anything, except in libmpg123
when built with clang.  The only problem is that the laptop only have
2GB ram, which is a little on the low side these days.
I also have a desktop set up in a similar way, but with a ATI graphics
card (HD4850) and a core2quad processor.  That one works splendid,
everything build with clang and linked with libc++ (as opposed to
libstdc++) and using ZFS as a boot file system
In summary, it is definitely possible to run a FreeBSD desktop off of
current, and I've never experienced any big hiccoughs that were not very
much self-inflicted.
Regards!
-- 
Niclas

___
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: Possible bug in NFSv4 with krb5p security?

[Rick Macklem]

Elias Martenson wrote:
> On 12 February 2013 23:20, Rick Macklem < rmack...@uoguelph.ca >
> wrote:
> 
> 
> 
> 
> 
> 
> There is (in case you missed it on google):
> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup
> (Nothing much has changed since FreeBSD8, except the name of the
> client
> side patch for host based initiator credentials in the keytab file.)
> I was hoping others would add/update the wiki and it would eventually
> become FreeBSD doc, but that hasn't happened.
> 
> 
> 
> 
> Thank you for the link. I have indeed found that, and I have followed
> it to the letter.
> 
> 
> I have up the exact same thing from Ubuntu machines as well as from
> Solaris, and I do have a fairly good understanding of Kerberos.
> FreeBSD however, is pretty new to me.
> 
> 
> Other than that, the various discussions in the archive on this list
> may help. Unfortunately, I don't know of an easy way to figure out
> what is busted. I always suggest looking at the packets in wireshark,
> but for some reason, I get the impression that folk don't like
> doing this? It is what I do first when I run into NFS issues.
> 
> 
> 
> I've been looking at the dumps using Wireshark. Well, I had to drop
> down the security since everything is encrypted when using keb5p. I do
> get the same errors using sec=krb5.
> 
> 
> When looking at this trace, I see a normal OPEN request followed by a
> NFS4ERR_ACCESS as a reply. The Kerberos credentials are of course
> encrypted, so I can't really say anything about that part.
> 
Well, it sounds like you are doing all the right stuff, so I don't know
why it is returning EACCES?

I'm not a ZFS person, so I never test that. If you have a UFS file system
you could export for testing, that might be worth a try. ZFS likes to do
things differently;-)

You can look at the authentication stuff in the RPC header:
Actually, the credentials in the RPC header aren't encrypted, although
they are binary data. It's been a while since I looked at the RFC, but
the authenticator is basically:
- an RPCSEC_GSS version (must be 1 for FreeBSD to be able to use it)
- a type that will be DATA in this case
- a credential handle (just a blob of bits the server uses as a shorthand
for the principal)
- a sequence# used to subvert replay attempts

Then the authentication verifier is an encrypted checksum of the above,
that the server uses to verify it.

All the Kerberos stuff happens via NFS Null RPCs, where the GSSAPI tokens
are passed as data (a Null RPC has no arguments) and the credential handle
and a session key get established. (The Kerberos ticket is inside the GSSAPI
token for the first of these Null RPCs.)

> 
> Note that NFS4 with Kerberos security never uses the user ID numbers.
> They purely use the Kerberos principals for authorisation. This is
> different from the default "sys" security model that blindly uses user
> ID's.
> 
Yep, of course. The Kerberos user principal "name@REALM" is translated
to a uid + gid list by the gssd via a lookup of "name" as the username.
The uid + gid list is then associated with that credential handle I mentioned
above.

> 
> 
> 
> > nfscbd_enable="YES"
> Needed for client side only, and only if delegations are
> enabled at the server and you want the client to acquire
> delegations. (Delegations are not enabled by default on the
> FreeBSD NFSv4 server.)
> 
> 
> 
> Noted. Thank you. I will change this.
> 
> 
> 
> > rpc_lockd_enable="YES"
> > rpc_statd_enable="YES"
> You shouldn't need rpc_lockd or rpc_statd for NFSv4,
> since they are only used for NFSv3.
> 
> 
> 
> Good point. I'll disable those too.
> 
> 
> 
> I don't know why a Linux client would mix NFSv3 RPCs with NFSv4 ones,
> 
> 
> I was suggested to set vfs.nfsd.server_min_nfsvers to 4 in order to
> completely disable NFS version below 4. I did this and got rid of the
> stray NFS3 requests. It didn't solve the original problem though.
> 
> 
> 
> > If anyone is able to confirm whether or not this actually has been
> > tested
> > in 9.1-CURRENT, I'd appreciate it. Also, if not, then I'd love to
> > know
> > where I should start looking for a solution. I'm experienced in
> > system
> > level programming (having worked on Solaris at Sun in a previous
> > life), but
> > a pointer where to start would be helpful.
> >
> Usually, when everything is being done by "nobody", it indicates that
> the mapping between  <-> name@domain isn't working
> correctly.
> (Looking at the packets in wireshark, you need to look at the
> attributes
> called Owner and Owner_Group to see what they are being set to.)
> 
> 
> 
> I actually doubt this. First of all, I have the correct idmapd setup
> working from FreeBSD to Ubuntu (I can see that since I can see the
> correct user names in "ls" even though the user ID's differ). On OSX I
> haven't got it to work yet.
> 
> 
> But, the behaviour is the same on both systems.
> 
> 
> This is actually expected, as the permission checks are orthogonal to
> the ID mapping.
> 
> 
> The most com

Re: vlan testing using etherswitchcfg

[Adrian Chadd]

On 12 February 2013 04:49, Yasir hussan  wrote:
> hi,
>
> is there anyone who knows how i can test vlan feature using *etherswitchcfg*,
> it tried to set and get vlan configuration for chip ar8316 it shows me
> right output like

Hi,

There's no switch support in the arswitch driver at the moment.

I'd love for someone to pipe up, extend etherswitch like what is done
in zrouter, and then add the few lines of code to arswitch to do it.



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: sysctl -a causes kernel trap 12

[Jakub Lach]

or rather hw.dri.0.info.i915_ringbuffer_data



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/sysctl-a-causes-kernel-trap-12-tp5775646p5786337.html
Sent from the freebsd-current mailing list archive at Nabble.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: sysctl -a causes kernel trap 12

[Jakub Lach]

If you were thinking about the same as me, is 
there some switch to curb hw.dri.0.info.i915_gem_hws output?



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/sysctl-a-causes-kernel-trap-12-tp5775646p5786336.html
Sent from the freebsd-current mailing list archive at Nabble.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: 7+ days of dogfood

[Warren Block]

On Mon, 11 Feb 2013, Lars Engels wrote:


I also dislike that src build times increased over the years since I run
CURRENT on my notebooks (starting 7-CURRENT, now 10-CURRENT).
Wouldn't it be possible to add a
DO_NOT_BUILD_CLANG_AND_GCC_IF_NOTHING_CHANGED= yes switch to src.conf?

Building clang takes ages and gcc is also pretty big...


devel/ccache really makes a gcc system buildworld a lot faster.  I don't 
know why more people don't use it; why recompile so many things that 
have not changed?


My recollection of testing it with clang was that it did not make much 
of an improvement.  Could be better 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: Possible bug in NFSv4 with krb5p security?

[Elias Mårtenson]

On 12 February 2013 23:20, Rick Macklem  wrote:

There is (in case you missed it on google):
> http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup
> (Nothing much has changed since FreeBSD8, except the name of the client
>  side patch for host based initiator credentials in the keytab file.)
> I was hoping others would add/update the wiki and it would eventually
> become FreeBSD doc, but that hasn't happened.
>
>
Thank you for the link. I have indeed found that, and I have followed it to
the letter.

I have up the exact same thing from Ubuntu machines as well as from
Solaris, and I do have a fairly good understanding of Kerberos. FreeBSD
however, is pretty new to me.


> Other than that, the various discussions in the archive on this list
> may help. Unfortunately, I don't know of an easy way to figure out
> what is busted. I always suggest looking at the packets in wireshark,
> but for some reason, I get the impression that folk don't like
> doing this? It is what I do first when I run into NFS issues.
>

I've been looking at the dumps using Wireshark. Well, I had to drop down
the security since everything is encrypted when using keb5p. I do get the
same errors using sec=krb5.

When looking at this trace, I see a normal OPEN request followed by a
NFS4ERR_ACCESS as a reply. The Kerberos credentials are of course
encrypted, so I can't really say anything about that part.

Note that NFS4 with Kerberos security never uses the user ID numbers. They
purely use the Kerberos principals for authorisation. This is different
from the default "sys" security model that blindly uses user ID's.


> > nfscbd_enable="YES"
> Needed for client side only, and only if delegations are
> enabled at the server and you want the client to acquire
> delegations. (Delegations are not enabled by default on the
> FreeBSD NFSv4 server.)
>

Noted. Thank you. I will change this.


> > rpc_lockd_enable="YES"
> > rpc_statd_enable="YES"
> You shouldn't need rpc_lockd or rpc_statd for NFSv4,
> since they are only used for NFSv3.
>

Good point. I'll disable those too.


> I don't know why a Linux client would mix NFSv3 RPCs with NFSv4 ones,
>

I was suggested to set vfs.nfsd.server_min_nfsvers to 4 in order to
completely disable NFS version below 4. I did this and got rid of the stray
NFS3 requests. It didn't solve the original problem though.


> > If anyone is able to confirm whether or not this actually has been
> > tested
> > in 9.1-CURRENT, I'd appreciate it. Also, if not, then I'd love to know
> > where I should start looking for a solution. I'm experienced in system
> > level programming (having worked on Solaris at Sun in a previous
> > life), but
> > a pointer where to start would be helpful.
> >
> Usually, when everything is being done by "nobody", it indicates that
> the mapping between  <-> name@domain isn't working correctly.
> (Looking at the packets in wireshark, you need to look at the attributes
>  called Owner and Owner_Group to see what they are being set to.)
>

I actually doubt this. First of all, I have the correct idmapd setup
working from FreeBSD to Ubuntu (I can see that since I can see the correct
user names in "ls" even though the user ID's differ). On OSX I haven't got
it to work yet.

But, the behaviour is the same on both systems.

This is actually expected, as the permission checks are orthogonal to the
ID mapping.


> The most common problem (since you do have nfsuserd running on the server)
> is for the "domain" spec to be different between client and server.
> FreeBSD's nfsuserd defaults to the domain part of the machine's hostname.
> Linux's rpc.idmapd sets the domain from /etc/idmapd.conf (at least I think
> that's what it is called) and many distros ship with it set to "my.domain"
> or something like that.
>

Correct. I have set this correctly. I know this, since once I did, "ls"
started giving me the correct user names.


> As such, I'd start by checking the Linux client and seeing what it has for
> the domain spec. in /etc/idmapd.conf.
>
> If you want to override the default for FreeBSD, there is a command line
> option for nfsuserd to do this. I can't remember what it is, but "man
> nfsuserd"
> will give you the answer and it can be set in /etc/rc.conf using
> nfsuserd_flags.
>

Thank you. I'm definitely willing to double-check this and I am not going
to claim to know exactly what's going on in the realms of NFS security. :-)


> If this is configured correctly, then looking at the packets in wireshark
> is
> the best starting point w.r.t. figuring out what is broken. I do limited
> testing of this and it works for me. I don't know how many others use it,
> although some definitely have fun getting it working. (Usually it is the
> Kerberos part on the client side that causes the most grief.)
>

It certainly is fun. But it gets frustrating when one fights a single
problem for weeks on end.

Far too few shops use Kerberos though.

Regards,
Elias
__

Re: Possible bug in NFSv4 with krb5p security?

[Rick Macklem]

Elias Martenson wrote:
> First of all, I used the "bug" word in the subject, and I'm not doing
> that
> lightly. I fully understand that the initial reaction to such claim is
> "he
> did something wrong", and frankly, that's what I'm hoping.
> 
> I've spent the last two weeks trying to get an NFS share working with
> krb5p
> security from a FreeBSD server to OSX and Ubuntu clients. I've
> followed all
> the documentation, read everything Google could find for me, asked on
> the
> IRC channel and even asked on Stackexchange, all to no avail.
> 
There is (in case you missed it on google):
http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup
(Nothing much has changed since FreeBSD8, except the name of the client
 side patch for host based initiator credentials in the keytab file.)
I was hoping others would add/update the wiki and it would eventually
become FreeBSD doc, but that hasn't happened.

Feel free to add to the wiki. All you need is a google login.

Other than that, the various discussions in the archive on this list
may help. Unfortunately, I don't know of an easy way to figure out
what is busted. I always suggest looking at the packets in wireshark,
but for some reason, I get the impression that folk don't like
doing this? It is what I do first when I run into NFS issues.

> In all my reading, something struck me as odd: Nowhere did I find any
> indication that anyone has actually set this up on 9.1-CURRENT. After
> receiving zero replies on Stackexchange I started to think that
> perhaps
> this is actually a bug.
> 
> Now, after all this talk, please let me explain what I've done. Most
> of
> this text is taken verbatim from my Stackexchange question here:
> 
> http://serverfault.com/questions/477118/permissions-are-not-taking-effect-with-kerberised-nfsv4-on-freebsd
> 
> Problem summary
> ===
> 
> My goal is to achieve the following:
> 
> - Files served from the FreeBSD system
> - The only security model should be krb5p
> - Clients are Linux (Ubuntu) and OSX
> 
> The problem that I'm facing is that even though the Kerberos
> authentication
> works, all accesses are performed using the user "nobody".
> 
> I can see the permissions when I do "ls -l". Even the user mapping
> works
> correctly, but unless "nobody" has permission to do anything with the
> files, I get a permission denied.
> 
> Here's an example interaction from the client (Ubuntu in this case,
> but the
> same thing happens from OSX). In this example,
> /export/shared/testshare is
> the shared directory from the FreeBSD server:
> 
> (I have changed the actual domain name to `domain` and the Kerberos
> realm
> name to `REALM`)
> 
> $ kinit
> Password for elias@REALM:
> $ klist
> Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
> Default principal: elias@REALM
> 
> Valid starting Expires Service principal
> 09/02/2013 09:40:47 10/02/2013 09:40:44 krbtgt/REALM@REALM
> $ sudo mount -t nfs4 -osec=krb5p,vers=4 lion:/export/shared/testshare
> /mnt
> $ ls -l /mnt
> total 4
> -rw-r--r-- 1 nobody nogroup 5 Feb 7 18:17 bar.txt
> -rw--- 1 elias nogroup 4 Feb 5 23:09 foo.txt
> $ cat /mnt/bar.txt
> blah
> $ echo foo >>/mnt/bar.txt
> bash: /mnt/bar.txt: Permission denied
> $ cat /mnt/foo.txt
> cat: /mnt/foo.txt: Permission denied
> $ klist
> Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
> Default principal: elias@REALM
> 
> Valid starting Expires Service principal
> 09/02/2013 09:40:47 10/02/2013 09:40:44 krbtgt/REALM@REALM
> 09/02/2013 09:41:56 10/02/2013 09:40:44 nfs/lion.domain@REALM
> 
> Server configuration
> 
> 
> I have had quite some problems in finding a comprehensive guide to
> setting
> up NFSv4 on FreeBSD. This is somewhat surprising in itself as I have
> found
> that information on how to do things in FreeBSD to be very good.
> 
> Here are the relevant lines in /etc/rc.conf:
> 
> rpcbind_enable="YES"
> nfs_server_enable="YES"
> nfsv4_server_enable="YES"
> nfsuserd_enable="YES"
> nfscbd_enable="YES"
Needed for client side only, and only if delegations are
enabled at the server and you want the client to acquire
delegations. (Delegations are not enabled by default on the
FreeBSD NFSv4 server.)

> mountd_enable="YES"
> gssd_enable="YES"
> rpc_lockd_enable="YES"
> rpc_statd_enable="YES"
You shouldn't need rpc_lockd or rpc_statd for NFSv4,
since they are only used for NFSv3.

> zfs_enable="YES"
> 
> Here is the content of /etc/exports:
> 
> /export/shared/testshare -sec=krb5p
> V4: / -sec=krb5p
> 
> Another interesting aspect is that when I used `tcpdump` to record the
> NFS
> network traffic between the client and the server, I saw NFS3 packets
> together with the NFS4 packets. Both of these packet types contained
> encrypted data, so I still think Kerberos was used, but given the
> configuration above, I would have expected there to be nothing but
> NFS4
> traffic.
> 
I don't know why a Linux client would mix NFSv3 RPCs with NFSv4 ones,
but you can look at a raw packet capture done by tcpdump in wiresh

Re: [RFC] USB keyboard and devd.conf

[Marius Strobl]

On Mon, Feb 11, 2013 at 01:43:29PM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> Does anyone need these lines in /etc/devd.conf ?
> 
> === etc/devd.conf
> ==
> --- etc/devd.conf (revision 246620)
> +++ etc/devd.conf (local)
> @@ -105,16 +105,6 @@
>  #action "sleep 2 && /usr/sbin/ath3kfw -d $device-name -f 
> /usr/local/etc/ath3k-1.fw";
>  #};
>  
> -# When a USB keyboard arrives, attach it as the console keyboard.
> -attach 100 {
> - device-name "ukbd0";
> - action "/etc/rc.d/syscons setkeyboard /dev/ukbd0";
> -};
> -detach 100 {
> - device-name "ukbd0";
> - action "/etc/rc.d/syscons setkeyboard /dev/kbd0";
> -};
> -
>  notify 100 {
>   match "system" "DEVFS";
>   match "subsystem" "CDEV";
> 
> 
> I plan to remove the lines marked with minus, because we now have kbdmux.
> 

Do these entries have negative impact on systems using kbdmux(4)?
Will their lack have impact on systems not using kbdmux(4)? I typically
remove or at least disable the latter on machines without atkbd(4) etc.
hardware and thus ukbd(4) is the only keyboard driver ever used there.

Marius

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

vlan testing using etherswitchcfg

[Yasir hussan]

hi,

is there anyone who knows how i can test vlan feature using *etherswitchcfg*,
it tried to set and get vlan configuration for chip ar8316 it shows me
right output like

#etherswitchcfg
port0:
vlangroup: 1
media: Ethernet 1000baseT 
status: active
port1:
vlangroup: 1025
media: Ethernet autoselect (none)
status: no carrier
port2:
vlangroup: 1
media: Ethernet autoselect (none)
status: no carrier
port3:
vlangroup: 1
media: Ethernet autoselect (none)
status: no carrier
port4:
vlangroup: 1
media: Ethernet autoselect (none)
status: no carrier
vlangroup0:
vlan: 0
members 1t,2t,3t,4t
vlangroup1:
vlan: 1
members 2
vlangroup2:
vlan: 0
members 0t,1t,3t,4t
vlangroup3:
vlan: 0
members 0t,1t,2t,4t
vlangroup4:
vlan: 0
members 0t,1t,2t,3t
vlangroup5:
vlan: 0
members 0t,1t,2t,3t,4t

but i still dont know how i should test it with its limited commands.i have
used vlan feature on a NetGear switch, i still can find how i can assign
LAN IP to a vlan and use it later...

Plz anyone who knows i can test vlan feature with this.

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: sysctl -a causes kernel trap 12

[Henri Hennebert]

On 01/19/2013 06:58, Brandon Gooch wrote:
> On Fri, Jan 18, 2013 at 2:56 PM, Xin Li  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 01/18/13 12:50, Brandon Gooch wrote:
>>> On Thu, Jan 10, 2013 at 4:25 PM, Xin Li >> > wrote:
>>>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>> To all: this became more and more hard to replicate lately.  I've
>>> tried these options and the most important progress is that it's
>>> possible to get a crashdump when debug.debugger_on_panic=0 and I
>>> managed to get a backtrace which indicates the panic occur when
>>> trying to do mtx_lock(&Giant) -> __mtx_lock_sleep -> turnstile_wait
>>> -> propagate_priority, but after I've added some instruments to
>>> the surrounding code and enabled INVARIANT and/or WITNESS, it
>>> mysteriously went away.
>>>
>>> Reverting my instruments code and update to latest svn makes the
>>> issue disappear for one day.  I've hit it again today but
>>> unfortunately didn't get a successful dump and after reboot I can't
>>> reproduce it again :(
>>>
>>> Still trying...
>>>
>>>
>>> Any updates Xin?
>>
>> No, it mysteriously disappeared for now.  According to my
>> understanding to recent svn commits, I didn't see anybody committing
>> something that fixes it but I can no longer panic my system, with or
>> without debugging code :(
>>
>>> I was actually hitting what I believe to be exactly the same issue
>>> as you on one of my systems, and, as you've seen, adding any extra
>>> debugging or diagnostics seemed to eliminate the issue.
>>>
>>> I was able to generate quite a few vmcores and still have these
>>> sitting around in my filesystem (along with the kernels that helped
>>> produce them).
>>>
>>> I can recreate this crash on my system by compiling the NVIDIA
>>> driver with clang at -01 and above. Although it's been noted that
>>> this issue has been seen in scenarios without an NIVIDIA driver in
>>> the mix, whatever is happening in the kernel to cause the panic is
>>> somehow triggered by this, at least on my system.
>>
>> I'm not sure if this is the same problem.  Could you please try using
>> gcc to compile the nVIdia driver and see if that "fixes" the problem?
>>
>> Cheers,
>> - --
>> Xin LI https://www.delphij.net/
>> FreeBSD - The Power to Serve!   Live free or die
>>
> 
> Indeed, a gcc compiled NVIDIA module eliminates the issue, sorry if I
> hadn't mentioned this earlier.
> 
> What was happening to me at first was that my system would just hang while
> booting. I was able to figure out that it was during /etc/rc.d/initrandom.
> I actually got to a point where I removed the call to sysctl -a from
> 'better_than_nothing()' in /etc/rc.d/initrandom to have a booting system. I
> finally had a situation where I could get a panic by adding SW_WATCHDOG to
> my kernel and running watchdogd(8).
> 
> For me, this panic would come and go seemingly at random as well, and I
> couldn't fumble my way around in the debugger to learn much of anything
> when I first started seeing it. I just started a process of modularizing
> everything I could in my kernel config, then loading modules 1-by-1 and
> booting over-and-over until I finally found what appeared to be the
> problem, which was the NVIDIA module compiled with clang.
> 
> Oh, another thing: at times it seemed as though it was the number of
> modules loaded, as I could get the hang with 41 modules loaded, but not 40
> or 42?! I admit, when I was seeing that behavior, I hadn't eliminated the
> NVIDIA driver from my loaded modules. I need to revisit the panic situation
> to confirm this particular strangeness.
> 
> Here's the last panic I had:
> 
> Unread portion of the kernel message buffer:
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 1175 (sysctl)
> 
> (kgdb) bt
> #0  doadump (textdump=1694704112) at pcpu.h:229
> #1  0x802fab82 in db_fncall (dummy1=,
> dummy2=, dummy3=, dummy4= optimized out>) at /usr/src/sys/ddb/db_command.c:578
> #2  0x802fa85a in db_command (last_cmdp=,
> cmd_table=, dopager=1) at
> /usr/src/sys/ddb/db_command.c:449
> #3  0x802fa612 in db_command_loop () at
> /usr/src/sys/ddb/db_command.c:502
> #4  0x802fcf60 in db_trap (type=, code=0) at
> /usr/src/sys/ddb/db_main.c:231
> #5  0x804a7b93 in kdb_trap (type=12, code=0, tf= out>) at /usr/src/sys/kern/subr_kdb.c:654
> #6  0x807157c5 in trap_fatal (frame=0xff8865032670, eva= optimized out>) at /usr/src/sys/amd64/amd64/trap.c:867
> #7  0x80715adb in trap_pfault (frame=0x0, usermode=0) at
> /usr/src/sys/amd64/amd64/trap.c:698
> #8  0x8071529b in trap (frame=0xff8865032670) at
> /usr/src/sys/amd64/amd64/trap.c:463
> #9  0x806ff382 in calltrap () at exception.S:228
> #10 0x8047bd50 in sysctl_sysctl_next_ls (lsp=,
> name=0xff8865032a80, namelen=,
> next=0xff8

Re: 7+ days of dogfood

[Anton Shterenlikht]

Date: Tue, 12 Feb 2013 02:48:49 -0800 (PST)
From: Jakub Lach 
To: freebsd-current@freebsd.org

Hi Anton, I recognize you from your
usual struggle with ia64 :) 

Hope your work/environment really have a good 
justification for keeping them around...

I'm a stubborn donkey.
As lons as Marcel has not abandoned it,
I'll use it.

Regarding work/environment - the University
has become about as stale, boring, risk averse,
unimaginative as can be, with regard to
computers, computing enviroment and general IT
support attitudes. What is a poor user to do?
I make a fuss. I complain to anybody and everybody.
I'm trying to convice the director of IT and
his varioius deputies, that they must recognise
the diversity of computing needs in engineering.
Windows desktop just doesn't do it for everybody.

More to the point, I belive by using ia64,
I contribute, in a small way, to the development
of FreeBSD, e.g. sometimes ia64 code breakages
indicate poor coding, and fixing code on ia64
actually fixes it on other arches too.

With a massive help from linimon@ we managed
last time to build over 15k ports on ia64 9 and 10.
So things are not that bad.

I would actually set only -march= because it should 
set mtune to the same value by default too.

Moreover, I suspect mckinley is an alias for itanium2, 
as it was it's codename...

Strangely, current gcc documentation for ia64 is 
missing references of march and mtune for ia64.

http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/IA_002d64-Options.html

There's no "-march", but for "-mtune" it says:

-mtune=cpu-type
Tune the instruction scheduling for a particular CPU, Valid values are 
itanium, itanium1, merced, itanium2, and mckinley. 

Thanks

Anton
___
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: 7+ days of dogfood

[Jakub Lach]

Actually there _is_ reference to mtune in doc, so probably only your first 
choice of mtune itanium2 would work, sorry for the noise.



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/7-days-of-dogfood-tp5785452p5786250.html
Sent from the freebsd-current mailing list archive at Nabble.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: 7+ days of dogfood

[Jakub Lach]

Hi Anton, I recognize you from your
usual struggle with ia64 :) 

Hope your work/environment really have a good 
justification for keeping them around...
 
I would actually set only -march= because it should 
set mtune to the same value by default too.

Moreover, I suspect mckinley is an alias for itanium2, 
as it was it's codename...

Strangely, current gcc documentation for ia64 is 
missing references of march and mtune for ia64.

http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/IA_002d64-Options.html



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/7-days-of-dogfood-tp5785452p5786248.html
Sent from the freebsd-current mailing list archive at Nabble.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: 7+ days of dogfood

[Anton Shterenlikht]

From s...@troutmask.apl.washington.edu Sun Feb 10 19:06:10 2013

On Sun, Feb 10, 2013 at 06:51:23PM +, Anton Shterenlikht wrote:
>   Date: Sun, 10 Feb 2013 08:44:24 -0800
>   From: Steve Kargl 
>   To: Boris Samorodov 
>   Subject: Re: 7+ days of dogfood
> 
>   > >   FFLAGS = -O2 -pipe -march=native -mtune=native
>   > 
>   > I don't like using "=" for FLAGS at make.conf...
>   > 
>   > >   FFLAGS+= -funroll-loops -ftree-vectorize
>   > 
>   > ... as well as defaults overriding.
>   > 
> 
>   FFLAGS are the options used while compiling Fortran.  Having
>   spent years contributing to and testing gfortran, I am fairly
>   comfortable with these options.
> 
> Do you recommend these FFLAGS settings to all
> users of gfortran (via lang/gcc4x)?
> 

Yes.

> For example, I use blas, lapack, slatec, atlas, etc.
> Should I use these FFLAGS too?

Without knowing what options you currently use, I cannot
make a concrete recommendation other than I've extensive
tested the above options with my own codes and the
Polyhedron testsuite.  Oh, I do recommend that one should
avoid -ffast-math (unless one really understands what it
actually does).

You probably don't care, as you don't use ia64,
but just for the record, on ia64 r244834 with

# cat /etc/make.conf|grep FFLAGS
FFLAGS = -O2 -pipe -march=native -mtune=native
FFLAGS+= -funroll-loops -ftree-vectorize
#

I get building lapack:

gfortran47 -O2 -pipe -march=native -mtune=native -funroll-loops 
-ftree-vectorize -pg -c slatms.f -o slatms.o
gfortran47: error: unrecognized command line option '-march=native'
gfortran47: error: unrecognized argument in option '-mtune=native'
gfortran47: note: valid arguments to '-mtune=' are: itanium2 mckinley

This box is

CPU: Madison (1500 MHz Itanium 2)

so I guess I can try "-mtune=itanium2"

and probably have to drop "-march" completely.

Anyway, thank you for the recommendation.

Anton
-- 
Steve

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

Possible bug in NFSv4 with krb5p security?

[Elias Mårtenson]

First of all, I used the "bug" word in the subject, and I'm not doing that
lightly. I fully understand that the initial reaction to such claim is "he
did something wrong", and frankly, that's what I'm hoping.

I've spent the last two weeks trying to get an NFS share working with krb5p
security from a FreeBSD server to OSX and Ubuntu clients. I've followed all
the documentation, read everything Google could find for me, asked on the
IRC channel and even asked on Stackexchange, all to no avail.

In all my reading, something struck me as odd: Nowhere did I find any
indication that anyone has actually set this up on 9.1-CURRENT. After
receiving zero replies on Stackexchange I started to think that perhaps
this is actually a bug.

Now, after all this talk, please let me explain what I've done. Most of
this text is taken verbatim from my Stackexchange question here:

http://serverfault.com/questions/477118/permissions-are-not-taking-effect-with-kerberised-nfsv4-on-freebsd

Problem summary
===

My goal is to achieve the following:

 - Files served from the FreeBSD system
 - The only security model should be krb5p
 - Clients are Linux (Ubuntu) and OSX

The problem that I'm facing is that even though the Kerberos authentication
works, all accesses are performed using the user "nobody".

I can see the permissions when I do "ls -l". Even the user mapping works
correctly, but unless "nobody" has permission to do anything with the
files, I get a permission denied.

Here's an example interaction from the client (Ubuntu in this case, but the
same thing happens from OSX). In this example, /export/shared/testshare is
the shared directory from the FreeBSD server:

(I have changed the actual domain name to `domain` and the Kerberos realm
name to `REALM`)

$ kinit
Password for elias@REALM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting   Expires  Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
$ sudo mount -t nfs4 -osec=krb5p,vers=4 lion:/export/shared/testshare
/mnt
$ ls -l /mnt
total 4
-rw-r--r-- 1 nobody nogroup   5 Feb  7 18:17 bar.txt
-rw--- 1 elias  nogroup   4 Feb  5 23:09 foo.txt
$ cat /mnt/bar.txt
blah
$ echo foo >>/mnt/bar.txt
bash: /mnt/bar.txt: Permission denied
$ cat /mnt/foo.txt
cat: /mnt/foo.txt: Permission denied
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting   Expires  Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
09/02/2013 09:41:56  10/02/2013 09:40:44  nfs/lion.domain@REALM

Server configuration


I have had quite some problems in finding a comprehensive guide to setting
up NFSv4 on FreeBSD. This is somewhat surprising in itself as I have found
that information on how to do things in FreeBSD to be very good.

Here are the relevant lines in /etc/rc.conf:

rpcbind_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
nfscbd_enable="YES"
mountd_enable="YES"
gssd_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
zfs_enable="YES"

Here is the content of /etc/exports:

/export/shared/testshare -sec=krb5p
V4: / -sec=krb5p

Another interesting aspect is that when I used `tcpdump` to record the NFS
network traffic between the client and the server, I saw NFS3 packets
together with the NFS4 packets. Both of these packet types contained
encrypted data, so I still think Kerberos was used, but given the
configuration above, I would have expected there to be nothing but NFS4
traffic.

If anyone is able to confirm whether or not this actually has been tested
in 9.1-CURRENT, I'd appreciate it. Also, if not, then I'd love to know
where I should start looking for a solution. I'm experienced in system
level programming (having worked on Solaris at Sun in a previous life), but
a pointer where to start would be helpful.

Thanks and regards,
Elias
___
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"