date:20160421

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

2016-04-21 Thread Gordon Ross

On Thu, Apr 21, 2016 at 9:53 PM, Gordon Ross  wrote:
> I'm not sure how anyone ever gets access when your ACL has this ACE:
> everyone@:rwxpdDaARWcCos:fd-:deny
>
> Every long has the group ...

Hah!   Spell checkers - Gr!   That should have read:

Every logon  has the group...
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

2016-04-21 Thread Gordon Ross

I'm not sure how anyone ever gets access when your ACL has this ACE:
everyone@:rwxpdDaARWcCos:fd-:deny

Every long has the group "everyone" as a member, therefore that ACE
will match every logon.  The ace also lists every possible permission,
so nothing should get through, no matter what allow ACEs might also
exist.

One thing to be aware of is that ZFS (and Unix in general) checks
Execute access when you try to "traverse" through a directory (path
name resolution).  If you're copying ACLs from a Windows server, you
may need to add some ACEs at various levels in your file hierarchy to
grant execute to whatever users and/or groups should be able to
traverse.
(The easiest way would be: chmod A+everyone@:x:fd:allow)

Windows servers normally run with a special privilege that makes the
SMB server threads exempt from traverse permission checking, for
reasons of efficiency.

On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi  wrote:
> I updated as indicated in the guide and to do that I had to uninstall some
> packages:
>
> serf@1.3.8,5.11-0.151014:20151015T214958Z
> apr-util@1.4.1,5.11-0.151014:20150508T204811Z
> apr@1.5.1,5.11-0.151014:20150529T175834Z
> uuid@1.41.14,5.11-0.151014:20150508T153803Z
>
> After reboot I got two main issues.
>
> 1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I usually did in
> the past, both for SMB, local webserver/services, ... but I can still access
> the box when I use the plain IP.
>
> OmniOS-Xeon:~ olaf$ cat /etc/nodename
> OmniOS-Xeon
>
>
> 2) I cannot access one specific SMB share ("olaf") that was working
> perfectly before the update. Using the IP of the machine allows me to access
> the other shares, but not this one. It was also the one with the most
> restrictive access ACLs, but they look fine to me.
>
> OmniOS-Xeon:~ olaf$ sharemgr show
> ...
> zfs
> zfs/tank/home/olaf
>   /tank/home/olaf
> [and more shares, all working]
>
> OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
> total 34
> drwx--+ 15 olaf olaf  15 Oct 25 11:27 olaf
>   user:olaf:rwxpdDaARWcCos:fd-:allow
>group:2147483648:rwxpdDaARWcCos:fd-:allow
>   everyone@:rwxpdDaARWcCos:fd-:deny
>
> OmniOS-Xeon:~ olaf$ tail /var/adm/messages
> Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
> smbd[OMNIOS-XEON\olaf]: temporar share not found
> Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
> Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
> smbd[OMNIOS-XEON\olaf]: olaf share not found
> Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>
> As you can see, the last letter of the share name in /var/adm/messages gets
> cut for the share "temporary", but not for my own share "olaf". However, my
> own share is neither visible nor accessible, while the other ones are.
>
> Has anything changed about permissions with SMB2?
>
> Thanks
> Olaf
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LDAP and Active Directory via rfc2307

2016-04-21 Thread Michael Talbott

Sorry for the duplicate thread. My email client died when I hit send and I 
thought it didn't go the first time, but I guess it did :(


> On Apr 21, 2016, at 6:39 PM, Michael Talbott  wrote:
> 
> I've been trying to figure out where I'm going wrong and just can't seem to 
> pinpoint the problem. I'm trying to move a few servers away from winbind 
> which was using rfc2307 mappings for uid/gid mapping and use LDAP instead. 
> Using the below configuration username/userid groupname/groupid match the ids 
> set in AD. However, for some reason, getent group shows all the groups with 
> proper ids, but, none of the groups have any members in there :( getent 
> passwd seems to work fine. So I'm thinking I'm missing some critical mapping 
> to make this happen, but, just can't seem to figure out where I'm going 
> wrong. Oh, and I'm running r151018.
> 
> Any help is much appreciated.
> 
> By the way, once this is resolved, maybe it should get posted under here: 
> http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfiguringLDAP
> 
> 
> Here's what I use to bind:
> 
> # setup ldap like so
> ldapclient uninit
> ldapclient manual \
> -a credentialLevel=proxy \
> -a authenticationMethod=simple \
> -a "proxyDN=cn=xyz_ldap_service,cn=Users,dc=ad,dc=xyz,dc=com" \
> -a defaultSearchBase=dc=ad,dc=xyz,dc=com \
> -a domainName=ad.xyz.com \
> -a "defaultServerList=10.x.x.x" \
> -a attributeMap=passwd:gecos=cn \
> -a attributeMap=shadow:gecos=cn \
> -a attributeMap=group:gecos=cn \
> -a attributeMap=passwd:uid=sAMAccountName \
> -a attributeMap=shadow:uid=sAMAccountName \
> -a attributeMap=passwd:homedirectory=unixHomeDirectory \
> -a attributeMap=shadow:shadowLastChange=pwdLastSet \
> -a attributeMap=group:uniqueMember=member \
> -a objectClassMap=passwd:posixAccount=user \
> -a objectClassMap=shadow:shadowAccount=user \
> -a objectClassMap=group:posixGroup=group \
> -a 
> "serviceSearchDescriptor=group:dc=ad,dc=xyz,dc=com?sub?(&(objectClass=group)(gidNumber=*))"
>  \
> -a 
> "serviceSearchDescriptor=passwd:cn=users,dc=ad,dc=xyz,dc=com?sub?(&(objectClass=user)(uidNumber=*))"
> 
> #enter password when prompted
> 
> # remove "ldap" from all entries in /etc/nsswitch.conf except for passwd and 
> group
> cp /etc/nsswitch.dns /etc/nsswitch.conf
> sed -i 's@passwd: files@passwd: files ldap@g' /etc/nsswitch.conf
> sed -i 's@group:  files@group:  files ldap@g' /etc/nsswitch.conf
> 
> # restart ldap client
> svcadm disable svc:/network/ldap/client:default
> sleep 2
> svcadm enable svc:/network/ldap/client:default
> sleep 1
> svcs svc:/network/ldap/client:default
> nscd -i passwd
> 
> # sanity checks
> /usr/lib/ldap/ldap_cachemgr -g
> svcs \*ldap\*
> svcs -l network/ldap/client:default
> nscd -i passwd
> ldapclient list
> ldaplist passwd
> ldaplist group
> /usr/lib/ldap/ldap_cachemgr -g
> 
> # profit
> getent passwd
> getent group
> 

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] LDAP and Active Directory via rfc2307

2016-04-21 Thread Michael Talbott

I've been trying to figure out where I'm going wrong and just can't seem to 
pinpoint the problem. I'm trying to move a few servers away from winbind which 
was using rfc2307 mappings for uid/gid mapping and use LDAP instead. Using the 
below configuration username/userid groupname/groupid match the ids set in AD. 
However, for some reason, getent group shows all the groups with proper ids, 
but, none of the groups have any members in there :( getent passwd seems to 
work fine. So I'm thinking I'm missing some critical mapping to make this 
happen, but, just can't seem to figure out where I'm going wrong. Oh, and I'm 
running r151018.

Any help is much appreciated.

By the way, once this is resolved, maybe it should get posted under here: 
http://omnios.omniti.com/wiki.php/GeneralAdministration#ConfiguringLDAP


Here's what I use to bind:

# setup ldap like so
ldapclient uninit
ldapclient manual \
 -a credentialLevel=proxy \
 -a authenticationMethod=simple \
 -a "proxyDN=cn=xyz_ldap_service,cn=Users,dc=ad,dc=xyz,dc=com" \
 -a defaultSearchBase=dc=ad,dc=xyz,dc=com \
 -a domainName=ad.xyz.com \
 -a "defaultServerList=10.x.x.x" \
 -a attributeMap=passwd:gecos=cn \
 -a attributeMap=shadow:gecos=cn \
 -a attributeMap=group:gecos=cn \
 -a attributeMap=passwd:uid=sAMAccountName \
 -a attributeMap=shadow:uid=sAMAccountName \
 -a attributeMap=passwd:homedirectory=unixHomeDirectory \
 -a attributeMap=shadow:shadowLastChange=pwdLastSet \
 -a attributeMap=group:uniqueMember=member \
 -a objectClassMap=passwd:posixAccount=user \
 -a objectClassMap=shadow:shadowAccount=user \
 -a objectClassMap=group:posixGroup=group \
 -a 
"serviceSearchDescriptor=group:dc=ad,dc=xyz,dc=com?sub?(&(objectClass=group)(gidNumber=*))"
 \
 -a 
"serviceSearchDescriptor=passwd:cn=users,dc=ad,dc=xyz,dc=com?sub?(&(objectClass=user)(uidNumber=*))"

#enter password when prompted

# remove "ldap" from all entries in /etc/nsswitch.conf except for passwd and 
group
cp /etc/nsswitch.dns /etc/nsswitch.conf
sed -i 's@passwd: files@passwd: files ldap@g' /etc/nsswitch.conf
sed -i 's@group:  files@group:  files ldap@g' /etc/nsswitch.conf

# restart ldap client
svcadm disable svc:/network/ldap/client:default
sleep 2
svcadm enable svc:/network/ldap/client:default
sleep 1
svcs svc:/network/ldap/client:default
nscd -i passwd

# sanity checks
/usr/lib/ldap/ldap_cachemgr -g
svcs \*ldap\*
svcs -l network/ldap/client:default
nscd -i passwd
ldapclient list
ldaplist passwd
ldaplist group
/usr/lib/ldap/ldap_cachemgr -g

# profit
getent passwd
getent group

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LTS (r151014) April 21st update

2016-04-21 Thread Dan McDonald

It's not critical for people who don't use the GSSAPI *Key exchange*.

You're good.

Dan

Sent from my iPhone (typos, autocorrect, and all)

> On Apr 21, 2016, at 5:50 PM, Michael Rasmussen  wrote:
> 
> On Thu, 21 Apr 2016 17:17:32 -0400
> Dan McDonald  wrote:
> 
>> 
>> have the details.  A customer-critical ZFS bugfix suite (illumos 6841-6843) 
>> and some HW bumps highlight this update.
>> 
>> It's a rebuild of illumos-omnios, so a reboot will be necessary.  Release 
>> media (USB-DD, ISO, Kayak) has been updated too.
> The only changes/fix of importance to me is this:
> OpenSSH 7.2p2 fixes for GSSAPI key exchange
> 
> Provided we have disabled GSSAPI authorization how important will it be
> to update OpenSSH?
> 
> -- 
> Hilsen/Regards
> Michael Rasmussen
> 
> Get my public GnuPG keys:
> michael  rasmussen  cc
> http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
> mir  datanom  net
> http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
> mir  miras  org
> http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
> --
> /usr/games/fortune -es says:
>  It's more than magnificent-it's mediocre. -Samuel Goldwyn
> ___
> OmniOS-discuss mailing list
> OmniOS-discuss@lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] Wiki is slightly broken

2016-04-21 Thread Michael Rasmussen

Hi Dan,

The following error prevents the wiki to function under webkit based
browsers:

Mixed Content: The page at 'https://omnios.omniti.com/wiki.php/WikiStart' was 
loaded over a secure connection, but contains a form which targets an insecure 
endpoint 'http://omnios.omniti.com/post-attachment.php'. This endpoint should 
be made available over a secure connection.
about:blank:1 Mixed Content: The page at 
'https://omnios.omniti.com/wiki.php/WikiStart' was loaded over HTTPS, but 
requested an insecure resource 'http://omnios.omniti.com//mtrack.css'. This 
request has been blocked; the content must be served over HTTPS.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
The sheep that fly over your head are soon to land.


pgpRd1fruQVCk.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] LTS (r151014) April 21st update

2016-04-21 Thread Michael Rasmussen

On Thu, 21 Apr 2016 17:17:32 -0400
Dan McDonald  wrote:

> 
> have the details.  A customer-critical ZFS bugfix suite (illumos 6841-6843) 
> and some HW bumps highlight this update.
> 
> It's a rebuild of illumos-omnios, so a reboot will be necessary.  Release 
> media (USB-DD, ISO, Kayak) has been updated too.
> 
The only changes/fix of importance to me is this:
OpenSSH 7.2p2 fixes for GSSAPI key exchange

Provided we have disabled GSSAPI authorization how important will it be
to update OpenSSH?

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
  It's more than magnificent-it's mediocre. -Samuel Goldwyn


pgpNfzOLgaHYB.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

2016-04-21 Thread Dan McDonald

> On Apr 21, 2016, at 3:21 PM, Steven Ford  wrote:
> 
> Dan, since you made these commits, do you have any thoughts? Could these be 
> related?
> 

Those are both kernel panic fixers (improper release after failure).

The non-global-zone SMB/CIFS fixes went into r151016, along with other fixes.

https://www.listbox.com/member/archive/182179/2015/04/sort/time_rev/page/1/entry/5:475/20150428134823:C190ED2C-EDCE-11E4-98D2-8987C5A0D07F/

That's the illumos-gate flag day for SMB-in-a-zone.  There are other fixes 
around that time in illumos-gate that got sucked into illumos-omnios as well.  
I'd investigate those.

Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

2016-04-21 Thread Natxo Asenjo

Hi Olaf

On Thu, Apr 21, 2016 at 8:31 PM, Olaf Marzocchi  wrote:

> Thanks for the help.
> Well first of all, how can the SMB server require everyone to have
> read/execute access? no more private shares?
>
> Anyway, I got it working (for now) with:
>
> drwxr-xr-x+ 16 olaf olaf  16 Apr 21 20:25 olaf
>   user:olaf:rwxpdDaARWcCos:fd-:allow
>group:2147483648:rwxpdDaARWcCos:fd-:allow
>   everyone@:r-x---a-R-c--s:---:allow
>   everyone@:rwxpdDaARWcCos:fd-:deny
>
> Still, why am I able to access without issues another share that has
> (basically) the same permissions as I had on my folder?
>
> d-S---+ 27 root temps170 Apr 20 23:10 Temporary
>   user:olaf:rwxpdDaARWcCos:fd-:allow
>group:2147483648:rwxpdDaARWcCos:fd-:allow
>   user:transmis:--x---a-R-c--s:---:allow
>   everyone@:rwxpdDaARWcCos:fd-:deny
>
> I am member of group "temps" too.
> This seems strange to me... it doesn't make sense.
>
> It is working now, but any explanation? I don't like to have everyone rx
> permissions on my private folder, even if the ACLs will not propagate said
> permissions to its contents.
>

I do not know exactly what has changed but I can tell you private shares
still work.

This share is only accessible for one one user:

root@zfstank:/root# /usr/bin/ls -Vd /tank/fotos/
d-+311 root root 322 Mar 11 14:00 /tank/fotos/
  user:username:rwxpdDaARWcCos:fd-:allow
root@zfstank:/root# ls -ld /tank/fotos/
d-+ 311 root root 322 Mar 11 14:00 /tank/fotos/

I do not remember exactly when I set it up, but it has been working at
least since version 151014

HTH,

-- 
regards,
Natxo
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

2016-04-21 Thread Steven Ford

Olaf,

The large number of changes between the version of OpenIndiana I was
running and r151016 made it daunting to pinpoint the problem. If this is
the same problem, I think it's safe to say the change was between r151014
and r151016. I'm not very savvy with the source code but I'll take a look.

Regards,

Steve

On Thu, Apr 21, 2016 at 2:31 PM, Olaf Marzocchi  wrote:

> Thanks for the help.
> Well first of all, how can the SMB server require everyone to have
> read/execute access? no more private shares?
>
> Anyway, I got it working (for now) with:
>
> drwxr-xr-x+ 16 olaf olaf  16 Apr 21 20:25 olaf
>   user:olaf:rwxpdDaARWcCos:fd-:allow
>group:2147483648:rwxpdDaARWcCos:fd-:allow
>   everyone@:r-x---a-R-c--s:---:allow
>   everyone@:rwxpdDaARWcCos:fd-:deny
>
> Still, why am I able to access without issues another share that has
> (basically) the same permissions as I had on my folder?
>
> d-S---+ 27 root temps170 Apr 20 23:10 Temporary
>   user:olaf:rwxpdDaARWcCos:fd-:allow
>group:2147483648:rwxpdDaARWcCos:fd-:allow
>   user:transmis:--x---a-R-c--s:---:allow
>   everyone@:rwxpdDaARWcCos:fd-:deny
>
> I am member of group "temps" too.
> This seems strange to me... it doesn't make sense.
>
> It is working now, but any explanation? I don't like to have everyone rx
> permissions on my private folder, even if the ACLs will not propagate said
> permissions to its contents.
>
> Thanks
> Olaf
>
>
>
>
> On 21/04/2016 03:48, Steven Ford wrote:
>
>> Olaf,
>>
>> This reminds me a a problem I was having after updating to 151016. I
>> posted about it on stack exchange.
>> http://serverfault.com/questions/762160/where-is-my-zfs-smb-share. My
>> problem boiled down to the folder had needed everybody to have read
>> permissions for the SMB share to appear.
>>
>>
>> Hope this helps,
>>
>> Steve
>>
>>
>> On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi > > wrote:
>>
>> I updated as indicated in the guide and to do that I had to
>> uninstall some packages:
>>
>> serf@1.3.8,5.11-0.151014:20151015T214958Z
>> apr-util@1.4.1,5.11-0.151014:20150508T204811Z
>> apr@1.5.1,5.11-0.151014:20150529T175834Z
>> uuid@1.41.14,5.11-0.151014:20150508T153803Z
>>
>> After reboot I got two main issues.
>>
>> 1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I
>> usually did in the past, both for SMB, local webserver/services, ...
>> but I can still access the box when I use the plain IP.
>>
>> OmniOS-Xeon:~ olaf$ cat /etc/nodename
>> OmniOS-Xeon
>>
>>
>> 2) I cannot access one specific SMB share ("olaf") that was working
>> perfectly before the update. Using the IP of the machine allows me
>> to access the other shares, but not this one. It was also the one
>> with the most restrictive access ACLs, but they look fine to me.
>>
>> OmniOS-Xeon:~ olaf$ sharemgr show
>> ...
>> zfs
>>  zfs/tank/home/olaf
>>/tank/home/olaf
>> [and more shares, all working]
>>
>> OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
>> total 34
>> drwx--+ 15 olaf olaf  15 Oct 25 11:27 olaf
>>user:olaf:rwxpdDaARWcCos:fd-:allow
>> group:2147483648 > >:rwxpdDaARWcCos:fd-:allow
>>everyone@:rwxpdDaARWcCos:fd-:deny
>>
>> OmniOS-Xeon:~ olaf$ tail /var/adm/messages
>> Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>> smbd[OMNIOS-XEON\olaf]: temporar share not found
>> Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
>> Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>> smbd[OMNIOS-XEON\olaf]: olaf share not found
>> Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>>
>> As you can see, the last letter of the share name in
>> /var/adm/messages gets cut for the share "temporary", but not for my
>> own share "olaf". However, my own share is neither visible nor
>> accessible, while the other ones are.
>>
>> Has anything changed about permissions with SMB2?
>>
>> Thanks
>> Olaf
>> ___
>> OmniOS-discuss mailing list
>> OmniOS-discuss@lists.omniti.com > OmniOS-discuss@lists.omniti.com>
>> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>>
>>
>>
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

2016-04-21 Thread Steven Ford

Between r151014 and r151016, the only commits that look relevant to me are:

https://github.com/omniti-labs/illumos-omnios/commit/8f5190a540d64d2debee6664bbc740e4c38f5b7f
https://github.com/omniti-labs/illumos-omnios/commit/0f92170f1ec2737ee5a0e51b5f74093904811452

However, I am not familiar with the source code nor with system programming
in general.

Dan, since you made these commits, do you have any thoughts? Could these be
related?

Thanks,

Steve


On Thu, Apr 21, 2016 at 2:59 PM, Steven Ford  wrote:

> Olaf,
>
> The large number of changes between the version of OpenIndiana I was
> running and r151016 made it daunting to pinpoint the problem. If this is
> the same problem, I think it's safe to say the change was between r151014
> and r151016. I'm not very savvy with the source code but I'll take a look.
>
> Regards,
>
> Steve
>
> On Thu, Apr 21, 2016 at 2:31 PM, Olaf Marzocchi 
> wrote:
>
>> Thanks for the help.
>> Well first of all, how can the SMB server require everyone to have
>> read/execute access? no more private shares?
>>
>> Anyway, I got it working (for now) with:
>>
>> drwxr-xr-x+ 16 olaf olaf  16 Apr 21 20:25 olaf
>>   user:olaf:rwxpdDaARWcCos:fd-:allow
>>group:2147483648:rwxpdDaARWcCos:fd-:allow
>>   everyone@:r-x---a-R-c--s:---:allow
>>   everyone@:rwxpdDaARWcCos:fd-:deny
>>
>> Still, why am I able to access without issues another share that has
>> (basically) the same permissions as I had on my folder?
>>
>> d-S---+ 27 root temps170 Apr 20 23:10 Temporary
>>   user:olaf:rwxpdDaARWcCos:fd-:allow
>>group:2147483648:rwxpdDaARWcCos:fd-:allow
>>   user:transmis:--x---a-R-c--s:---:allow
>>   everyone@:rwxpdDaARWcCos:fd-:deny
>>
>> I am member of group "temps" too.
>> This seems strange to me... it doesn't make sense.
>>
>> It is working now, but any explanation? I don't like to have everyone rx
>> permissions on my private folder, even if the ACLs will not propagate said
>> permissions to its contents.
>>
>> Thanks
>> Olaf
>>
>>
>>
>>
>> On 21/04/2016 03:48, Steven Ford wrote:
>>
>>> Olaf,
>>>
>>> This reminds me a a problem I was having after updating to 151016. I
>>> posted about it on stack exchange.
>>> http://serverfault.com/questions/762160/where-is-my-zfs-smb-share. My
>>> problem boiled down to the folder had needed everybody to have read
>>> permissions for the SMB share to appear.
>>>
>>>
>>> Hope this helps,
>>>
>>> Steve
>>>
>>>
>>> On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi >> > wrote:
>>>
>>> I updated as indicated in the guide and to do that I had to
>>> uninstall some packages:
>>>
>>> serf@1.3.8,5.11-0.151014:20151015T214958Z
>>> apr-util@1.4.1,5.11-0.151014:20150508T204811Z
>>> apr@1.5.1,5.11-0.151014:20150529T175834Z
>>> uuid@1.41.14,5.11-0.151014:20150508T153803Z
>>>
>>> After reboot I got two main issues.
>>>
>>> 1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I
>>> usually did in the past, both for SMB, local webserver/services, ...
>>> but I can still access the box when I use the plain IP.
>>>
>>> OmniOS-Xeon:~ olaf$ cat /etc/nodename
>>> OmniOS-Xeon
>>>
>>>
>>> 2) I cannot access one specific SMB share ("olaf") that was working
>>> perfectly before the update. Using the IP of the machine allows me
>>> to access the other shares, but not this one. It was also the one
>>> with the most restrictive access ACLs, but they look fine to me.
>>>
>>> OmniOS-Xeon:~ olaf$ sharemgr show
>>> ...
>>> zfs
>>>  zfs/tank/home/olaf
>>>/tank/home/olaf
>>> [and more shares, all working]
>>>
>>> OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
>>> total 34
>>> drwx--+ 15 olaf olaf  15 Oct 25 11:27 olaf
>>>user:olaf:rwxpdDaARWcCos:fd-:allow
>>> group:2147483648 >> >:rwxpdDaARWcCos:fd-:allow
>>>everyone@:rwxpdDaARWcCos:fd-:deny
>>>
>>> OmniOS-Xeon:~ olaf$ tail /var/adm/messages
>>> Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>>> smbd[OMNIOS-XEON\olaf]: temporar share not found
>>> Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
>>> Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
>>> smbd[OMNIOS-XEON\olaf]: olaf share not found
>>> Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times
>>>
>>> As you can see, the last letter of the share name in
>>> /var/adm/messages gets cut for the share "temporary", but not for my
>>> own share "olaf". However, my own share is neither visible nor
>>> accessible, while the other ones are.
>>>
>>> Has anything changed about permissions with SMB2?
>>>
>>> Thanks
>>> Olaf
>>>

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

2016-04-21 Thread Olaf Marzocchi


Thanks for the help.
Well first of all, how can the SMB server require everyone to have 
read/execute access? no more private shares?


Anyway, I got it working (for now) with:

drwxr-xr-x+ 16 olaf olaf  16 Apr 21 20:25 olaf
  user:olaf:rwxpdDaARWcCos:fd-:allow
   group:2147483648:rwxpdDaARWcCos:fd-:allow
  everyone@:r-x---a-R-c--s:---:allow
  everyone@:rwxpdDaARWcCos:fd-:deny

Still, why am I able to access without issues another share that has 
(basically) the same permissions as I had on my folder?


d-S---+ 27 root temps170 Apr 20 23:10 Temporary
  user:olaf:rwxpdDaARWcCos:fd-:allow
   group:2147483648:rwxpdDaARWcCos:fd-:allow
  user:transmis:--x---a-R-c--s:---:allow
  everyone@:rwxpdDaARWcCos:fd-:deny

I am member of group "temps" too.
This seems strange to me... it doesn't make sense.

It is working now, but any explanation? I don't like to have everyone rx 
permissions on my private folder, even if the ACLs will not propagate 
said permissions to its contents.


Thanks
Olaf




On 21/04/2016 03:48, Steven Ford wrote:

Olaf,

This reminds me a a problem I was having after updating to 151016. I
posted about it on stack exchange.
http://serverfault.com/questions/762160/where-is-my-zfs-smb-share. My
problem boiled down to the folder had needed everybody to have read
permissions for the SMB share to appear.


Hope this helps,

Steve


On Wed, Apr 20, 2016 at 6:28 PM, Olaf Marzocchi > wrote:

I updated as indicated in the guide and to do that I had to
uninstall some packages:

serf@1.3.8,5.11-0.151014:20151015T214958Z
apr-util@1.4.1,5.11-0.151014:20150508T204811Z
apr@1.5.1,5.11-0.151014:20150529T175834Z
uuid@1.41.14,5.11-0.151014:20150508T153803Z

After reboot I got two main issues.

1) I cannot reach my OmniOS box with "OmniOS-Xeon.local" as I
usually did in the past, both for SMB, local webserver/services, ...
but I can still access the box when I use the plain IP.

OmniOS-Xeon:~ olaf$ cat /etc/nodename
OmniOS-Xeon


2) I cannot access one specific SMB share ("olaf") that was working
perfectly before the update. Using the IP of the machine allows me
to access the other shares, but not this one. It was also the one
with the most restrictive access ACLs, but they look fine to me.

OmniOS-Xeon:~ olaf$ sharemgr show
...
zfs
 zfs/tank/home/olaf
   /tank/home/olaf
[and more shares, all working]

OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
total 34
drwx--+ 15 olaf olaf  15 Oct 25 11:27 olaf
   user:olaf:rwxpdDaARWcCos:fd-:allow
group:2147483648 :rwxpdDaARWcCos:fd-:allow
   everyone@:rwxpdDaARWcCos:fd-:deny

OmniOS-Xeon:~ olaf$ tail /var/adm/messages
Apr 20 22:30:04 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
smbd[OMNIOS-XEON\olaf]: temporar share not found
Apr 20 22:30:04 OmniOS-Xeon last message repeated 10 times
Apr 20 22:30:33 OmniOS-Xeon smbsrv: [ID 138215 kern.notice] NOTICE:
smbd[OMNIOS-XEON\olaf]: olaf share not found
Apr 20 22:30:36 OmniOS-Xeon last message repeated 8 times

As you can see, the last letter of the share name in
/var/adm/messages gets cut for the share "temporary", but not for my
own share "olaf". However, my own share is neither visible nor
accessible, while the other ones are.

Has anything changed about permissions with SMB2?

Thanks
Olaf
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com 
http://lists.omniti.com/mailman/listinfo/omnios-discuss



___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

2016-04-21 Thread Olaf Marzocchi

Yes I saw it but it was about guest access, while my case is about a 
share restricted only to its owner because I wanted to be sure that 
private data stay private:


OmniOS-Xeon:~ olaf$ ls -lV /tank/home/
total 34
drwx--+ 15 olaf olaf  15 Oct 25 11:27 olaf
  user:olaf:rwxpdDaARWcCos:fd-:allow
   group:2147483648:rwxpdDaARWcCos:fd-:allow
  everyone@:rwxpdDaARWcCos:fd-:deny


Olaf


On 21/04/2016 01:25, Dan McDonald wrote:

Yes it has.  Did you see Gordon Ross's mail about it?

Dan

Sent from my iPhone (typos, autocorrect, and all)


On Apr 20, 2016, at 6:28 PM, Olaf Marzocchi  wrote:

Has anything changed about permissions with SMB2?

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Slow scrub on SSD-only pool

2016-04-21 Thread Richard Elling


> On Apr 21, 2016, at 7:47 AM, Chris Siebenmann  wrote:
> 
> [About ZFS scrub tunables:]
>> Interesting read - and it surely works. If you set the tunable before
>> you start the scrub you can immediately see the thoughput being much
>> higher than with the standard setting. [...]
> 
> It's perhaps worth noting here that the scrub rate shown in 'zpool
> status' is a cumulative one, ie the average scrub rate since the scrub
> started. As far as I know the only way to get the current scrub rate is
> run 'zpool status' twice with some time in between and then look at how
> much progress the scrub's made during that time.

Scrub rate measured in IOPS or bandwidth is not useful. Neither is a reflection
of the work being performed in ZFS nor the drives.

> 
> As such, increasing the scrub speed in the middle of what had been a
> slow scrub up to that point probably won't make a massive or immediate
> difference in the reported scrub rate. You should see it rising over
> time, especially if you drastically speeded it up, but it's not any sort
> of instant jump.
> 
> (You can always monitor iostat, but that mixes in other pool IO. There's
> probably something clever that can be done with DTrace.)

I've got some dtrace that will show progress. However, it is only marginally
useful when you've got multiple datasets.

> 
> This may already be obvious and well known to people, but I figured
> I'd mention it just in case.

People fret about scrubs and resilvers, when they really shouldn't. In ZFS
accessing data also checks and does recovery, so anything they regularly
access will be unaffected by the subsequent scan. Over the years, I've tried
several ways to approach teaching people about failures and scrubs/resilvers,
but with limited success: some people just like to be afraid... Hollywood makes
a lot of money on them :-)
 -- richard


___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Slow scrub on SSD-only pool

2016-04-21 Thread Chris Siebenmann

[About ZFS scrub tunables:]
> Interesting read - and it surely works. If you set the tunable before
> you start the scrub you can immediately see the thoughput being much
> higher than with the standard setting. [...]

 It's perhaps worth noting here that the scrub rate shown in 'zpool
status' is a cumulative one, ie the average scrub rate since the scrub
started. As far as I know the only way to get the current scrub rate is
run 'zpool status' twice with some time in between and then look at how
much progress the scrub's made during that time.

 As such, increasing the scrub speed in the middle of what had been a
slow scrub up to that point probably won't make a massive or immediate
difference in the reported scrub rate. You should see it rising over
time, especially if you drastically speeded it up, but it's not any sort
of instant jump.

(You can always monitor iostat, but that mixes in other pool IO. There's
probably something clever that can be done with DTrace.)

 This may already be obvious and well known to people, but I figured
I'd mention it just in case.

- cks
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] Slow scrub on SSD-only pool

2016-04-21 Thread Stephan Budach


Am 19.04.16 um 23:31 schrieb wuffers:

You might want to check this old thread:

http://lists.omniti.com/pipermail/omnios-discuss/2014-July/002927.html

Richard Elling had some interesting insights on how the scrub works:

"So I think the pool is not scheduling scrub I/Os very well. You can 
increase the number of
scrub I/Os in the scheduler by adjusting the zfs_vdev_scrub_max_active 
tunable. The
default is 2, but you'll have to consider that a share (in the stock 
market sense) where
the active sync reads and writes are getting 10 each. You can try 
bumping up the value
and see what happens over some time, perhaps 10 minutes or so -- too 
short of a time
and you won't get a good feeling for the impact (try this in off-peak 
time).

echo zfs_vdev_scrub_max_active/W0t5 | mdb -kw
will change the value from 2 to 5, increasing its share of the total 
I/O workload.


You can see the progress of scan (scrubs do scan) workload by looking 
at the ZFS

debug messages.
echo ::zfs_dbgmsg | mdb -k
These will look mysterious... they are. But the interesting bits are 
about how many blocks
are visited in some amount of time (txg sync interval). Ideally, this 
will change as you

adjust zfs_vdev_scrub_max_active."

I had to increase my zfs_vdev_scrub_max_active parameter higher than 
5, but it sounds like the default setting for that tunable is no 
longer satisfactory for today's high performance systems.


On Sun, Apr 17, 2016 at 4:07 PM, Stephan Budach > wrote:


Am 17.04.16 um 20:42 schrieb Dale Ghent:

On Apr 17, 2016, at 9:07 AM, Stephan Budach
> wrote:

Well… searching the net somewhat more thoroughfully, I
came across an archived discussion which deals also with a
similar issue. Somewhere down the conversation, this
parameter got suggested:

echo "zfs_scrub_delay/W0" | mdb -kw

I just tried that as well and although the caculated speed
climbs rathet slowly up, iostat now shows approx. 380 MB/s
read from the devices, which rates at 24 MB/s per single
device * 8 *2.

Being curious, I issued a echo "zfs_scrub_delay/W1" | mdb
-kw to see what would happen and that command immediately
drowned the rate on each device down to 1.4 MB/s…

What is the rational behind that? Who wants to wait for
weeks for a scrub to finish? Usually, I am having znapzend
run as well, creating snapshots on a regular basis.
Wouldn't that hurt scrub performance even more?

zfs_scrub_delay is described here:


http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#63

How busy are your disks if you subtract the IO caused by a
scrub? Are you doing these scrubs with your VMs causing normal
IO as well?

Scrubbing, overall, is treated as a background maintenance
process. As such, it is designed to not interfere with
"production IO" requests. It used to be that scrubs ran as
fast as disk IO and bus bandwidth would allow, which in turn
severely impacted the IO performance of running applications,
and in some cases this would cause problems for production or
user services.  The scrub delay setting which you've
discovered is the main governor of this scrub throttle
code[1], and by setting it to 0, you are effectively removing
the delay it imposes on itself to allow non-scrub/resilvering
IO requests to finish.

The solution in your case is specific to yourself and how you
operate your servers and services. Can you accept degraded
application IO while a scrub or resilver is running? Can you
not? Maybe only during certain times?

/dale

[1]

http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/dsl_scan.c#1841

I do get the notion if this, but if the increase from 0 to 1
reduces the throughput from 24Mb/s to 1MB/s, this seems way
overboard to me. Having to wait for a couple of hours when running
with 0 as opposed to days (up to 10) when running at 1  - on a 1.3
TB zpool - doesn't seem to be the right choice. If this tunable
offered some more room for choice, that would be great, but it
obviously doesn't.

It's the weekend and my VMs aren't excatly hogging their disks, so
there was plenty of I/O available… I'd wish for a more granular
setting regarding this setting.

Anyway, the scrub finished a couple of hours later and of course,
I can always set this tunable to 0, should I need it,

Thanks,

Stephan



Interesting read - and it surely works. If you set the tunable before 
you start the scrub you can immediately see the thoughput being much 
higher

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

Re: [OmniOS-discuss] LDAP and Active Directory via rfc2307

[OmniOS-discuss] LDAP and Active Directory via rfc2307

Re: [OmniOS-discuss] LTS (r151014) April 21st update

[OmniOS-discuss] Wiki is slightly broken

Re: [OmniOS-discuss] LTS (r151014) April 21st update

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

Re: [OmniOS-discuss] SMB issues after r151014 -> r151018

Re: [OmniOS-discuss] Slow scrub on SSD-only pool

Re: [OmniOS-discuss] Slow scrub on SSD-only pool

Re: [OmniOS-discuss] Slow scrub on SSD-only pool

16 matches

Site Navigation

Mail list logo

Footer information