Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread Reginald Beardsley


--- On Mon, 2/25/13, James Relph ja...@themacplace.co.uk wrote:

 From: James Relph ja...@themacplace.co.uk
 Subject: [OpenIndiana-discuss] idmap timeout
 To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org
 Date: Monday, February 25, 2013, 7:44 AM
 Hi all,
 
 Another idmap issue!  Just trying a new VM for some
 troubleshooting and I can't seem to get the
 name_cache_timeout and id_cache_timeout settings to work on
 here.  I've run:
 
 svccfg -s svc:/system/idmap setprop
 config/name_cache_timeout=count: 31536000
 svccfg -s svc:/system/idmap setprop
 config/id_cache_timeout=count: 31536000
 
 but I'm still seeing UIDs changing every 10 minutes (cron
 job here running an id to a file every minute):
 
 13:05:00   uid=2147491845
 gid=2147483650(Domain Users@themacplace.private)
 13:06:00   uid=2147491845
 gid=2147483650(Domain Users@themacplace.private)
 13:07:00   uid=2147491845
 gid=2147483650(Domain Users@themacplace.private)
 13:08:00   uid=2147491845
 gid=2147483650(Domain Users@themacplace.private)
 13:09:00   uid=2147491845
 gid=2147483650(Domain Users@themacplace.private)
 13:10:00   uid=2147491845
 gid=2147483650(Domain Users@themacplace.private)
 13:11:00   uid=2147491846(james@themacplace.private)
 gid=2147483650(Domain Users@themacplace.private)
 13:12:00   uid=2147491846(james@themacplace.private)
 gid=2147483650(Domain Users@themacplace.private)
 13:13:00   uid=2147491846
 gid=2147483650(Domain Users@themacplace.private)
 13:14:00   uid=2147491846
 gid=2147483650(Domain Users@themacplace.private)
 13:15:00   uid=2147491846
 gid=2147483650(Domain Users@themacplace.private)
 13:16:00   uid=2147491846
 gid=2147483650(Domain Users@themacplace.private)
 13:17:00   uid=2147491846
 gid=2147483650(Domain Users@themacplace.private)
 
 Does anyone know if this is a bug, or expected
 behaviour?  Obviously doesn't affect CIFS at all, but
 I'm trying to do some troubleshooting against another
 service.  What also seems a bit weird is the output
 format of id changes when the id ticks over (adds the
 username into brackets)?
 

What does

svccfg -s svc:/system/idmap listprop config/* 

show after making the settings?  Also, did you svcadm restart idmap after 
setting the timeouts?

What are you using to make the query in the cron job?  Checking idmap.db per 
the notes in feature #677 shows the expiration time being set properly in the 
database in oi_151a7.  

Have Fun!
Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread James Relph
Hi Reg,

 svccfg -s svc:/system/idmap listprop config/* 

config/list_size_limit  count0
config/stabilityastring  Unstable
config/value_authorization  astring  solaris.smf.value.idmap
config/machine_sid  astring  S-1-5-21-3389328288-2012474116-2712525247
config/domain_name  astring  themacplace.private
config/name_cache_timeout   count31536000
config/id_cache_timeout count31536000


  Also, did you svcadm restart idmap after setting the timeouts?

Yep!

 What are you using to make the query in the cron job?  

#/bin/bash
datestring=$(date +%H:%M:%S)
userdata=$(/usr/bin/id james@themacplace.private)
echo $datestring   $userdata  /root/idtest.log

 Checking idmap.db per the notes in feature #677 shows the expiration time 
 being set properly in the database in oi_151a7.  

Yeah, I did that, and the expiration time did change:

INSERT INTO idmap_cache 
VALUES('S-1-5-21-422489907-454740634-3148902543',1105,'themacplace.private','james','james',2147500059,NULL,1,1,1,1,4,NULL,NULL,NULL,NULL,NULL,NULL,0,1393348328)

The current epoch time is 1361813013, so 1393348328 - 1361813013 gives 
31535315, so it looks like it's working absolutely fine in terms of changing 
the settings, it just doesn't appear to be having much effect.  I've left it 
running and it's still doing it!

17:11:00   uid=2147500057 gid=2147483650(Domain Users@themacplace.private)
17:12:00   uid=2147500058(james@themacplace.private) gid=2147483650(Domain 
Users@themacplace.private)
17:13:00   uid=2147500058(james@themacplace.private) gid=2147483650(Domain 
Users@themacplace.private)
17:14:00   uid=2147500058(james@themacplace.private) gid=2147483650(Domain 
Users@themacplace.private)
17:15:00   uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:16:00   uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:17:00   uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:18:00   uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:19:00   uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:20:00   uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:21:00   uid=2147500058 gid=2147483650(Domain Users@themacplace.private)
17:22:00   uid=2147500059 gid=2147483650(Domain Users@themacplace.private)
17:23:00   uid=2147500059 gid=2147483650(Domain Users@themacplace.private)
17:24:00   uid=2147500059 gid=2147483650(Domain Users@themacplace.private)

Cheers,

James.




___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread Jim Klimov

On 2013-02-25 20:22, James Relph wrote:

  Also, did you svcadm restart idmap after setting the timeouts?


Yep!


Just in case, you also did svcadm refresh idmap after changing SMF
service properties and before restarting the service, right? ;)

//Jim


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread James Relph
 Just in case, you also did svcadm refresh idmap after changing SMF
 service properties and before restarting the service, right? ;)

I think so, although you've got me wondering now.  Although saying that, it's 
appearing correctly in the idmap database, so presumably I did and that should 
be in effect anyway?

James.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread Jim Klimov

On 2013-02-25 21:12, James Relph wrote:

Just in case, you also did svcadm refresh idmap after changing SMF
service properties and before restarting the service, right? ;)


I think so, although you've got me wondering now.  Although saying that, it's 
appearing correctly in the idmap database, so presumably I did and that should 
be in effect anyway?


Just in case, do it then - won't hurt.
I was bitten more than once that svccfg changes the SMF definitions
database, but the running-config is stored in another SMF database -
and the refresh action replicates the changed config bits. Otherwise
even a reboot (IIRC) won't enable your most recent SMF changes.

I may be wrong though, and this may be experience from an older distro
and not applicable to OI, but still...

//Jim



___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread Reginald Beardsley
James,

Try modifying your cron job to do a:

idmap dump -nv

each time it goes off.  I am not seeing that output change, nor am I seeing the 
contents of idmap.db change over time as things expire.  But they might be 
intended to remain to allow
reconnections w/ the same mapping.

Writing a static set of name rules using awk should be pretty trivial if one 
can query Windows and Mac OS for authorized user name lists.  Updating could be 
triggered by a request that didn't have a mapping yet.  This would then all 
persist across boots.


Have Fun!
Reg


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread James Relph
 I did think of that, but it's things like triggering that, keeping it up to 
 date (ie. when users are removed from AD) and the rest, and I thought it 
 might become quite a big project really and something that may be better 
 written as some kind of alternate idmap option (i.e. instead of just having 
 static and ephemeral, have static, ephemeral and cached - with cached 
 basically being automatically created user mappings).

When I say cached I mean a cached copy of the users in AD (with some ADs that 
could be a big ask though...).

I added idmap dump -nv | grep james to the script, and I'm getting effectively 
the same issue:

18:56:00   uid=2147508227 gid=2147483650(Domain Users@themacplace.private)
18:56:00   winuser:james@themacplace.private==  uid:2147508228
18:57:00   uid=2147508227 gid=2147483650(Domain Users@themacplace.private)
18:57:00   winuser:james@themacplace.private==  uid:2147508228
18:58:00   uid=2147508227 gid=2147483650(Domain Users@themacplace.private)
18:58:00   winuser:james@themacplace.private==  uid:2147508228
18:59:00   uid=2147508228(james@themacplace.private) gid=2147483650(Domain 
Users@themacplace.private)
18:59:00   winuser:james@themacplace.private==  uid:2147508229
19:00:00   uid=2147508228(james@themacplace.private) gid=2147483650(Domain 
Users@themacplace.private)
19:00:00   winuser:james@themacplace.private==  uid:2147508229
19:01:00   uid=2147508228 gid=2147483650(Domain Users@themacplace.private)
19:01:00   winuser:james@themacplace.private==  uid:2147508229

The id command seems to lag a little behind the idmap dump command, I'm 
guessing a cached problem there.  Still, they do still keep changing...

James.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread Reginald Beardsley


--- On Mon, 2/25/13, James Relph ja...@themacplace.co.uk wrote:

 From: James Relph ja...@themacplace.co.uk
 Subject: Re: [OpenIndiana-discuss] idmap timeout
 To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org
 Date: Monday, February 25, 2013, 3:00 PM
 
  Try modifying your cron job to do a:
  
  idmap dump -nv
 
 I'll add that in, see what drops out.
 
  Writing a static set of name rules using awk should be
 pretty trivial if one can query Windows and Mac OS for
 authorized user name lists.  Updating could be
 triggered by a request that didn't have a mapping yet. 
 This would then all persist across boots.
 
 I did think of that, but it's things like triggering that,
 keeping it up to date (ie. when users are removed from AD)
 and the rest, and I thought it might become quite a big
 project really and something that may be better written as
 some kind of alternate idmap option (i.e. instead of just
 having static and ephemeral, have static, ephemeral and
 cached - with cached basically being automatically created
 user mappings).
 
 To be fair if idmap was able to just use static mapping to a
 range of IDs that would be good enough.

Unless I've badly misunderstood what I've read it can do that now.  Of course, 
comments and code are not always in agreement.  Or perhaps  the more common, 
However, if you did that then, you can't do this now.

Ignoring that the only limitation I see is what will Windows  Mac OS reveal 
w/o requiring installing a program. If OI can query the AD hosts, then idmap 
can trigger an update on a fail of identifier lookup.  That's a pretty clean 
change.  One function call in the right place.  Or update every 5 minutes and 
there's no change needed.  Just a cron job.

Have Fun!
Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread Reginald Beardsley


--- On Mon, 2/25/13, James Relph ja...@themacplace.co.uk wrote:

 From: James Relph ja...@themacplace.co.uk
 Subject: Re: [OpenIndiana-discuss] idmap timeout
 To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org
 Date: Monday, February 25, 2013, 3:18 PM
  I did think of that, but it's
 things like triggering that, keeping it up to date (ie. when
 users are removed from AD) and the rest, and I thought it
 might become quite a big project really and something that
 may be better written as some kind of alternate idmap option
 (i.e. instead of just having static and ephemeral, have
 static, ephemeral and cached - with cached basically being
 automatically created user mappings).
 
 When I say cached I mean a cached copy of the users in AD
 (with some ADs that could be a big ask though...).
 
 I added idmap dump -nv | grep james to the script, and I'm
 getting effectively the same issue:
 
 18:56:00   uid=2147508227
 gid=2147483650(Domain Users@themacplace.private)
 18:56:00   winuser:james@themacplace.private   
 ==    uid:2147508228
 18:57:00   uid=2147508227
 gid=2147483650(Domain Users@themacplace.private)
 18:57:00   winuser:james@themacplace.private   
 ==    uid:2147508228
 18:58:00   uid=2147508227
 gid=2147483650(Domain Users@themacplace.private)
 18:58:00   winuser:james@themacplace.private   
 ==    uid:2147508228
 18:59:00   uid=2147508228(james@themacplace.private)
 gid=2147483650(Domain Users@themacplace.private)
 18:59:00   winuser:james@themacplace.private   
 ==    uid:2147508229
 19:00:00   uid=2147508228(james@themacplace.private)
 gid=2147483650(Domain Users@themacplace.private)
 19:00:00   winuser:james@themacplace.private   
 ==    uid:2147508229
 19:01:00   uid=2147508228
 gid=2147483650(Domain Users@themacplace.private)
 19:01:00   winuser:james@themacplace.private   
 ==    uid:2147508229
 
 The id command seems to lag a little behind the idmap dump
 command, I'm guessing a cached problem there.  Still,
 they do still keep changing...
 

Dump the database too.

Do you suppose Windows could be resetting the connection?  I'm generating 
ephemeral map entries that hang around in the tables.  But I'm doing it on OI.  
No Windows.

Maybe it's a signalling glitch.  MS is using a reset operation as a keep alive? 
 Wouldn't be the first time an interface got confused.

Have Fun!
Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread Reginald Beardsley


--- On Mon, 2/25/13, James Relph ja...@themacplace.co.uk wrote:

 From: James Relph ja...@themacplace.co.uk
 Subject: Re: [OpenIndiana-discuss] idmap timeout
 To: Discussion list for OpenIndiana openindiana-discuss@openindiana.org
 Date: Monday, February 25, 2013, 4:47 PM
 
  Unless I've badly misunderstood what I've read it can
 do that now.  Of course, comments and code are not
 always in agreement.  Or perhaps  the more common,
 However, if you did that then, you can't do this now.
 
 The thing is that there doesn't seem to be anything anywhere
 that actually says ephemeral IDs will persist. 
 There's a cache, which you can change the timeouts for, but
 from what I can see it either updates the cache anyway, or
 updates the UID of cached objects.

Are you saying there's another copy besides idmap.db?  I'd not seen evidence of 
that.

I *think* the idea is you scan a list returned by the database and check the 
expiration stamp of the items relative to the epoch.  Negative items are 
ignored.  The least positive entry is selected, and the loop sleeps on that 
timer.  I'm sure there are subtleties I missed as I went pretty quickly.  But 
it's a common pattern that fits the requirement.

 
  Ignoring that the only limitation I see is what will
 Windows  Mac OS reveal w/o requiring installing a
 program. If OI can query the AD hosts, then idmap can
 trigger an update on a fail of identifier lookup. 
 That's a pretty clean change.  One function call in the
 right place.
 
 It's getting someone who can write the function call that is
 tricky!

The hard part is finding one person who understands the internals of 3 systems 
well.  

Given a program which will run on OI and return a text file w/ the current set 
of user IDs in the host domain, the rest is trivial.  It's a non-blocking 
fork-exec of the update program. On a rare event it's as non-invasive as it 
gets.

An alternative would be to have Windows provide everything in a CIFS share and 
access that from idmap.  That might be attractive from a security perspective 
if access can be tightly controlled.

And of course, what does Mac OS do?

Have Fun!
Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] idmap timeout

2013-02-25 Thread James Relph

 Are you saying there's another copy besides idmap.db?  I'd not seen evidence 
 of that.

No, but even if an object is already in the cache, it still seems to be 
updating the UID.  It doesn't seem to be the case that an entry in the idmap 
cache is a static entry.  Either that or the cache timeout settings just aren't 
actually being used correctly (it is odd that this is changing every 10 minutes 
- which is the default cache time).

 The hard part is finding one person who understands the internals of 3 
 systems well.  

They shouldn't really need to; OS X uses LDAP natively if you use OS X Server 
(uncommon) so that would just work straight away, no problems there.  In terms 
of what we though most of the time Mac users will be accessing with Active 
Directory credentials (because that's what enterprises tend to use these days).

 Given a program which will run on OI and return a text file w/ the current 
 set of user IDs in the host domain, the rest is trivial.  It's a non-blocking 
 fork-exec of the update program. On a rare event it's as non-invasive as it 
 gets.

The thing is that the whole problem with Active Directory is that (natively) it 
doesn't have user IDs, it has SIDs - so you need to look up the SID and then 
generate a UID.  This is what winbind and Mac OS X do and importantly their 
mappings are automatically generated, but static.  So if user jbloggs logs into 
an OS X system bound to AD, he gets a UID generated for him, and that will 
always be his UID (on a Mac bound to that AD - it's generated based on the 
SID).  The problem with ephemeral IDs is the ephemeral part!  If you could just 
have an idmap setting which was basically:

use IDs 5-75000 for AD users

that would solve the problem, once an AD user access the system they get 
assigned a fixed UID.  As mentioned OS X is slightly more clever as the UID is 
generated procedurally from information from the AD, but that would be nice, 
rather than critical.  Basically if you could have idmap so it would do:

S-1-5-21-422489907-454740634-3148902543   2147483650

with the Windows SID on the left and the UNIX UID on the right, and have that 
not change, that would be it.  You can do that now by doing name based 
mappings, so you can get:

S-1-5-21-422489907-454740634-3148902543   name-of-local-user

but it isn't automatic and it's a bit inflexible.  You could write a bash 
script that did:

-   LDAP query of AD to get user and group names
-   Create matching users and groups on Oi system
-   Create static maps between AD users/groups and Oi users/groups

I wouldn't think that would be fast though, and I wouldn't know the best way of 
triggering it.

James.

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss