On 8 apr 2010, at 23.21, Miles Nordin wrote:
>> "rs" == Ragnar Sundblad writes:
>
>rs> use IPSEC to make IP address spoofing harder.
>
> IPsec with channel binding is win, but not until SA's are offloaded to
> the NIC and all NIC's can do IPsec AES at line rate. Until this
> happens y
mingli writes:
> Thank Erik, and I will try it, but the new question is that the root
> of the NFS server mapped as nobody at the NFS client.
>
> For this issue, I set up a new test NFS server and NFS client, and
> with the same option, at this test environment, the file owner
> mapped correctly,
> "rs" == Ragnar Sundblad writes:
rs> use IPSEC to make IP address spoofing harder.
IPsec with channel binding is win, but not until SA's are offloaded to
the NIC and all NIC's can do IPsec AES at line rate. Until this
happens you need to accept there will be some protocols used on SAN
On 12 mar 2010, at 03.58, Damon Atkins wrote:
...
> Unfortunately DNS spoofing exists, which means forward lookups can be poison.
And IP address spoofing, and...
> The best (maybe only) way to make NFS secure is NFSv4 and Kerb5 used together.
Amen!
DNS is NOT an authentication system!
IP is NO
If you're getting nobody:nobody on an NFS mount you have an NFS version
mismatch, (usually between V3 & V4) to get around this use the following as
mount options on the client:
hard,bg,intr,vers=3
e.g:
mount -o hard,bg,intr,vers=3 server:/pool/zfs /mountpoint
--
This message posted from opens
Thank Erik, and I will try it, but the new question is that the root of the
NFS server mapped as nobody at the NFS client.
For this issue, I set up a new test NFS server and NFS client, and with the
same option, at this test environment, the file owner mapped correctly, it
confused me.
Thank
pantzer5 wrote:
>
> > These days I am a fan for forward check access
> lists, because any one who
> > owns a DNS server can say that for IPAddressX
> returns aserver.google.com.
> > They can not set the forward lookup outside of
> their domain but they can
> > setup a reverse lookup. The other adv
> These days I am a fan for forward check access lists, because any one who
> owns a DNS server can say that for IPAddressX returns aserver.google.com.
> They can not set the forward lookup outside of their domain but they can
> setup a reverse lookup. The other advantage is forword looking access
In /etc/hosts for the format is
IP FQDN Alias...
Which would means "1.1.1.1 aserver.google.com aserver aserver-le0"
I have seen a lot of sysadmins do the following:
"1.1.1.1 aserver aserver.google.com"
which means the host file (or NIS) does not match DNS
As the first entry is FQDN it is then "nam
On 3/10/2010 3:27 PM, Robert Thurlow wrote:
As said earlier, it's the string returned from the reverse DNS lookup
that needs to be matched.
So, to make a long story short, if you log into the server
from the client and do "who am i", you will get the host
name you need for the share.
Anothe
> "dc" == Dennis Clarke writes:
dc> zfs set
dc> sharenfs=nosub\,nosuid\,rw\=hostname1\:hostname2\,root\=hostname2
dc> zpoolname/zfsname/pathname
>> wth? Commas and colons are not special characters. This is
>> silly.
dc> Works real well.
I said it was silly, not
On 03/11/10 09:27 AM, Robert Thurlow wrote:
Ian Collins wrote:
On 03/11/10 05:42 AM, Andrew Daugherity wrote:
I've found that when using hostnames in the sharenfs line, I had to use
the FQDN; the short hostname did not work, even though both client and
server were in the same DNS domain and t
>> "ea" == erik ableson writes:
>> "dc" == Dennis Clarke writes:
>
> >> "rw,ro...@100.198.100.0/24", it works fine, and the NFS client
> >> can do the write without error.
>
> ea> I' ve found that the NFS host based settings required the
> ea> FQDN, and that the reverse
Ian Collins wrote:
On 03/11/10 05:42 AM, Andrew Daugherity wrote:
I've found that when using hostnames in the sharenfs line, I had to use
the FQDN; the short hostname did not work, even though both client and
server were in the same DNS domain and that domain is in the search
path, and nsswitc
> "ea" == erik ableson writes:
> "dc" == Dennis Clarke writes:
>> "rw,ro...@100.198.100.0/24", it works fine, and the NFS client
>> can do the write without error.
ea> I' ve found that the NFS host based settings required the
ea> FQDN, and that the reverse lookup must
On 03/11/10 05:42 AM, Andrew Daugherity wrote:
On Tue, 2010-03-09 at 20:47 -0800, mingli wrote:
And I update the sharenfs option with "rw,ro...@100.198.100.0/24", it works
fine, and the NFS client can do the write without error.
Thanks.
I've found that when using hostnames in the sh
"Andrew Daugherity" writes:
>> And I update the sharenfs option with "rw,ro...@100.198.100.0/24",
>> it works fine, and the NFS client can do the write without error.
>>
>> Thanks.
>
> I've found that when using hostnames in the sharenfs line, I had to use
> the FQDN; the short hostname did not
On Tue, 2010-03-09 at 20:47 -0800, mingli wrote:
> And I update the sharenfs option with "rw,ro...@100.198.100.0/24", it works
> fine, and the NFS client can do the write without error.
>
> Thanks.
I've found that when using hostnames in the sharenfs line, I had to use
the FQDN; the short hostna
I' ve found that the NFS host based settings required the FQDN, and that the
reverse lookup must be available in your DNS.
Try "rw,root=host1.mydomain.net"
Cheers,
Erik
On 10 mars 2010, at 05:47, mingli wrote:
> And I update the sharenfs option with "rw,ro...@100.198.100.0/24", it works
> fin
And I update the sharenfs option with "rw,ro...@100.198.100.0/24", it works
fine, and the NFS client can do the write without error.
Thanks.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mai
> Hi All,
> I had create a ZFS filesystem test and shared it with "zfs set
> sharenfs=root=host1 test", and I checked the sharenfs option and it
> already update to "root=host1":
Try to use a backslash to escape those special chars like so :
zfs set sharenfs=nosub\,nosuid\,rw\=hostname1\:hostna
Hi All,
I had create a ZFS filesystem test and shared it with "zfs set
sharenfs=root=host1 test", and I checked the sharenfs option and it already
update to "root=host1":
bash-3.00# zfs get sharenfs test
-
22 matches
Mail list logo
