Sure - I've got tomorrow off, so it will be Friday morning.
cheers
L.
--
The most dangerous phrase in the language is, "We've always done it this
way."
- Grace Hopper
On 20 July 2016 at 17:14, Jakub Hrozek wrote:
> On Wed, Jul 20, 2016 at 09:28:06AM +1000, Lachlan Musicman wrote:
> > On 1
On Wed, Jul 20, 2016 at 09:28:06AM +1000, Lachlan Musicman wrote:
> On 19 July 2016 at 16:40, Jakub Hrozek wrote:
>
> > On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > > I think the thing that frustrates the most is that id u...@domain.com is
> > > returning correct data on
On 19 July 2016 at 16:40, Jakub Hrozek wrote:
> On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > I think the thing that frustrates the most is that id u...@domain.com is
> > returning correct data on both but they can't loginand I can't even
> > show that this is the case
On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> I think the thing that frustrates the most is that id u...@domain.com is
> returning correct data on both but they can't loginand I can't even
> show that this is the case because now they can login. Difficult to
> reproduce :/
I think the thing that frustrates the most is that id u...@domain.com is
returning correct data on both but they can't loginand I can't even
show that this is the case because now they can login. Difficult to
reproduce :/
--
The most dangerous phrase in the language is, "We've always done
Ok, the bad news is that it didn't last. We are still having the same
problem - HBAC is rejecting users because not all jobs are being discovered
on the host.
I turned the debug_level up to 10 as requested, but to be honest, it's
impossible to find anything in the logs because it's so verbose - su
On Mon, Jul 18, 2016 at 09:17:06AM +1000, Lachlan Musicman wrote:
> Previously we did have the default_domain_suffix set, but we had to unset
> it. I can't remember why we had to - something to do with
> ownership/permissions and our filesystem (IBM v7000) not playing nice iirc.
> We really wanted
Previously we did have the default_domain_suffix set, but we had to unset
it. I can't remember why we had to - something to do with
ownership/permissions and our filesystem (IBM v7000) not playing nice iirc.
We really wanted to use the dds => the researchers are complaining of
broken brains due to
On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> I've updated all the relevant hosts and the FreeIPA server to the COPR sssd
> 1.14.0 release and the problem seems to have disappeared.
Great, but please keep an eye on the machine, the 1.14 branch is still
kindof fresh and we did
I've updated all the relevant hosts and the FreeIPA server to the COPR sssd
1.14.0 release and the problem seems to have disappeared.
Cheers
L.
--
The most dangerous phrase in the language is, "We've always done it this
way."
- Grace Hopper
On 15 July 2016 at 10:09, Lachlan Musicman wrote:
AH. I'm seeing a lot of this now.
hbac_eval_user_element is returning the wrong number of groups.
I just found another instance in my logs :
(Fri Jul 15 08:39:04 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_eval_user_element] (0x1000): [23] groups for [SimpsonLachlan]
IPA server
[root@vmpr-lin
On 14 July 2016 at 17:44, Sumit Bose wrote:
> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
> >
> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
> >
> > Installed Packages
> > Name: ipa
On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
>
> FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
>
> Installed Packages
> Name: ipa-server
> Arch: x86_64
> Version : 4.2.0
> Rel
Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
Installed Packages
Name: ipa-server
Arch: x86_64
Version : 4.2.0
Release : 15.0.1.el7.centos.17
Size: 5.0 M
Repo: installed
>From re
On Tue, Jul 12, 2016 at 09:08:01AM +1000, Lachlan Musicman wrote:
> Alex, Sumit,
>
> Which log levels would you recommend for sssd to help debug this issue?
>
> We've been using 7, but I just realised that it's not an increasing scale
> but bitmasked...
It is both 0-9 is increasing scale while v
Alex, Sumit,
Which log levels would you recommend for sssd to help debug this issue?
We've been using 7, but I just realised that it's not an increasing scale
but bitmasked...
cheers
L.
--
The most dangerous phrase in the language is, "We've always done it this
way."
- Grace Hopper
On 11
On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> On 11 July 2016 at 16:44, Alexander Bokovoy wrote:
>
> > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> >
> >> Hola,
> >>
> >> Centos 7, up to date.
> >>
> >> [root@linuxidm ~]# ipa --version
> >> VERSION: 4.2.0, API_VERSION: 2.1
On 11 July 2016 at 16:44, Alexander Bokovoy wrote:
> On Mon, 11 Jul 2016, Lachlan Musicman wrote:
>
>> Hola,
>>
>> Centos 7, up to date.
>>
>> [root@linuxidm ~]# ipa --version
>> VERSION: 4.2.0, API_VERSION: 2.156
>>
>> One way trust is successfully established, can login with
>>
>> ssh usern...@
On Mon, 11 Jul 2016, Lachlan Musicman wrote:
Hola,
Centos 7, up to date.
[root@linuxidm ~]# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156
One way trust is successfully established, can login with
ssh usern...@domain1.com@server1.domain2.com
Am testing to get HBAC to work.
I've noticed th
Hola,
Centos 7, up to date.
[root@linuxidm ~]# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156
One way trust is successfully established, can login with
ssh usern...@domain1.com@server1.domain2.com
Am testing to get HBAC to work.
I've noticed that with the Allow All rule in effect, the follo
20 matches
Mail list logo