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
--- On Mon, 2/25/13, James Relph wrote:
> From: James Relph
> Subject: [OpenIndiana-discuss] idmap timeout
> To: "Discussion list for OpenIndiana"
> Date: Monday, February 25, 2013, 7:44 AM
> Hi all,
>
> Another idmap issue! Just trying a new VM for some
>
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
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
___
> 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
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,
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 stat
--- On Mon, 2/25/13, Jim Klimov wrote:
> From: Jim Klimov
> Subject: Re: [OpenIndiana-discuss] idmap timeout
> To: openindiana-discuss@openindiana.org
> Date: Monday, February 25, 2013, 2:27 PM
> On 2013-02-25 21:12, James Relph
> wrote:
> >> Just in case, you als
> FWIW "svcadm restart idmap" loads the new setting properly on oi_151a7 w/o an
> "svcadm refresh idmap".
Yep, didn't make any difference:
18:30:00 uid=2147508225(james@themacplace.private) gid=2147483650(Domain
Users@themacplace.private)
18:31:00 uid=2147508225(james@themacplace.private) g
> 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
> 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 ju
--- On Mon, 2/25/13, James Relph wrote:
> From: James Relph
> Subject: Re: [OpenIndiana-discuss] idmap timeout
> To: "Discussion list for OpenIndiana"
> Date: Monday, February 25, 2013, 3:00 PM
>
> > Try modifying your cron job to do a:
> >
> >
> 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 sa
--- On Mon, 2/25/13, James Relph wrote:
> From: James Relph
> Subject: Re: [OpenIndiana-discuss] idmap timeout
> To: "Discussion list for OpenIndiana"
> Date: Monday, February 25, 2013, 3:18 PM
> > I did think of that, but it's
> things like triggering t
--- On Mon, 2/25/13, James Relph wrote:
> From: James Relph
> Subject: Re: [OpenIndiana-discuss] idmap timeout
> To: "Discussion list for OpenIndiana"
> Date: Monday, February 25, 2013, 4:47 PM
>
> > Unless I've badly misunderstood what I've read i
> 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 time
16 matches
Mail list logo
